John Day <jeanjour(_at_)comcast(_dot_)net> wrote:
At 11:34 -0500 2008/12/29, John Leslie wrote:
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.
To whatever extent we accept the existence of "transport" for
stationary computers, we must allow it for mobile computers.
I think we're arguing semantics here, without agreeing on what we
mean by "transport". I'd much rather continue that argument on a different
mailing-list.
Trying to guess where you are coming from, don't blame Transport for
TCP's faults.
TCP has many faults, only some of which are related to its "transport
layer" functions.
Where I'm coming from, BTW, is a long series of primal screams when
I hear someone proposing how to deal with transport issues in a
routing protocol.
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"
But, IMHO, we _never_have_ seen network-vs-transport in a consistent
way.
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 (or mobility, if you prefer) isn't about "discovering"
alternate connectivity: it's about verifying that something arriving
via a different path is in fact controlled by the same process as
something we're already communicating with. That is _not_ a routing
issue -- routing merely attempts to deliver packets.
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.
Even if we were to accept a flooding paradigm for routing (and send
every packet out every interface), multihoming would still require
sorting out which packets to trust.
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.
Although routing _does_ make such decisions, architecturally that's
noise, not a native "network layer" function. Network-layer is about
getting packets through a network of networks _at_all_ -- not about
managing everyone's Quality-of-Service wishlists. "Efficiency" issues
in routing are there to keep routing from breaking, for example by
routing packets in a loop until TTL is exhausted.
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.
Feel free to correct me -- what question should I be asking?
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.
I'd be happy to talk about that -- on the <tae(_at_)ietf(_dot_)org> list.
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.
To a routing algorithm, "nodes" are "nodes", period. True.
But in the Internet, IP addresses _are_ points of attachment, and
network-layer routing finds paths between "points of attachment".
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?
Not this week... ;^)
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf