No it isn't Transport's job. Transport has one and only one
purpose: end-to-end reliability and flow control.
"Managing" the resources of the network is the network
layer's job.
Although, these distinctions of Network and Transport Layer are .
. . shall we say, quaint.
Multihoming is fundamentally a routing problem. SCTP tries
to claim to solve it by changing the definition, an old trick. Sort of
like medieval medicine's response to a disease it can't cure:
give you a disease I can cure and hope it works. Multihoming has
nothing to do with what has traditionally been called the
"Transport Layer."
It is a problem of routing not be able to recognize that two
points of attachment go to the same place. Portraying it as
anything else is just deluding yourself.
At 14:22 +0100 2008/12/29, Rémi Després wrote:
John,
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)?
Thus, ordinary applications wouldn't need to be concerned.
RD
Actually SCTP is it to some extent.
John C Klensin - le (m/j/a) 12/29/08 1:56 PM:
--On Sunday, 28 December, 2008 16:22 -0500 John Day
<jeanjour@xxxxxxxxxxx> wrote:
Why should an application ever see an IP address?
Applications manipulating IP addresses is like a Java program
manipulating absolute memory pointers. A recipe for problems,
but then you already know that.
John,
Let me try to explain, in a slightly different way, what I
believe some others have tried to say.
Suppose we all agree with the above as a principle and even
accept your analogy (agreement isn't nearly that general, but
skip that for the moment). Now consider an IPv6 host or a
multihomed IPv4 host (as distinct from multihomed IPv4 network).
The host will typically have multiple interfaces, multiple IP
addresses, and, at least as we do things today and without other
changes in the architecture, only one name. One could change
the latter, but having the typical application know about
multiple interfaces is, in most cases, fully as bad as knowing
about the addresses -- one DNS name per interface is more or
less the same as one DNS name per address.
Now the application has to pick which interface to use in, e.g.,
opening a connection to another system.
See above
Doing that optimally,
or even effectively, requires that it know routing information.
But requiring the application to obtain and process routing
information is worse than whatever you think about its using IP
addresses -- the latter may be just a convenient handle ("blob")
to identify what we have historically called an interface, but
having the application process and interpret routing information
is completely novel as far as the applications layer is
concerned (as well as being a layer violation, etc., etc.) and
requires skills and knowledge that application writers rarely
have and still more rarely should need to use.
At least to me, that is the key architectural problem here, not
whatever nasty analogies one can draw about IP addresses.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf