Subject: Re: [tae] The internet architecture

From: John Leslie <[email-masked]>
Date: Mon, 29 Dec 2008 11:34:56 -0500

John Day <[email-masked]> 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.

   And, IMHO, from an architectural viewpoint, multi-homing and mobility
are the same problem.

> "Managing" the resources of the network is the network layer's job.

   That's only partly true, and completely irrelevant.

> 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."

> 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.

   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...)

   Multihoming _should_not_ wait for connectivity to fail altogether;
least of all should it wait for connectivity failure to propagate
through an internet.

   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.)

> 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.

> 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."

> 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.

> 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.

--
John Leslie <[email-masked]>
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae