John Day <jeanjour@xxxxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf