At 11:34 -0500 2008/12/29, John Leslie wrote:
John Day <jeanjour(_at_)comcast(_dot_)net> wrote:
At 14:22 +0100 2008/12/29, R?mi Despr?s wrote:
To pick a local interface for an outgoing connection[,]
isn't the transport layer, e.g. SCTP, well placed to do the job
(or some intermediate layer function like Shim6)?
No it isn't Transport's job. Transport has one and only one purpose:
end-to-end reliability and flow control.
I must disagree with John Day.
I accept "reliability and flow control" as the transport layer's
primary function, but denying it access to multiple interfaces cripples
its ability to perform those functions in a mobility environment.
Transport has nothing to do with mobility.
And, IMHO, from an architectural viewpoint, multi-homing and mobility
are the same problem.
You are absolutely right. Mobility is nothing more than dynamic multihoming.
Trying to guess where you are coming from, don't blame Transport for
TCP's faults.
"Managing" the resources of the network is the network layer's job.
That's only partly true, and completely irrelevant.
Highly relevant. Since only the network layer can manage the network layer.
Although, these distinctions of Network and Transport Layer are . . .
shall we say, quaint.
True, we can't seem to agree to a distinction and stick with it,
but "quaint" is hardly the right word -- it's more like "deja-vu all
over again."
No, quaint. As in "isn't it quaint how people saw things in olden times"
> Multihoming is fundamentally a routing problem.
Absolutely not.
Routing is a function of discovering connectivity and propagating
information about routes to routers that may want to use them.
Boy, if discovering routes and propagating routing information isn't
a routing problem, then what is?
Multihoming is a funtion of maintaining alternate paths in order
to avoid interruptions of connectivity when a primary path hiccups or
becomes congested. (Just like mobility...)
Right. Routing.
Multihoming _should_not_ wait for connectivity to fail altogether;
least of all should it wait for connectivity failure to propagate
through an internet.
That is a policy decision that routing is free to make and does.
We have pretty good routing algorithms for _stable_ networks. We
have to kludge those algorithms to work _at_all_ in unstable networks.
Mobility by its nature _cannot_ be stable. (Multi-homing is most
often done as protection against occasional instability.)
Of course it can. You just aren't asking the right question.
> SCTP tries to claim to solve it by changing the definition, an old
trick.
Unfair! SCTP was designed for a specific function: it's quite honest
about the design choices. Don't blame its design for other things folks
are trying to use it for.
Only blame ti for things its spec claims it does.
> Multihoming has nothing to do with what has traditionally been called
the "Transport Layer."
If so, perhaps it's time to refine those "definitions" of "Transport
Layer."
Eliminate the transport layer is probably the best thing to do.
> It is a problem of routing not be able to recognize that two points
of attachment go to the same place.
Hardly!
Routing finds paths between "nodes" using "links". These "nodes"
_are_ points of attachment, not computers (whatever those may be).
Routing _must_ deal in topology, not physical proximity.
Nodes are not points of attachments. Well, not to the same routing algorithm.
Portraying it as anything else is just deluding yourself.
Again, hardly!
We have been punting entirely too much to "routing" for decades.
There are other perfectly valid ways to divide the problem. And IMHO,
any way that makes the realm of "routing" reside in a "stable" space
is a _better_ paradigm.
O, and BTW, did I say we don't solve multihoming in routers either?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf