Re: [tae] [tsv-area] Transport negotiation

Stuart Cheshire <cheshire@apple.com> wrote:
> 
> Bryan Ford's excellent "Breaking Up the Transport Logjam"  
> presentation pointed out that what we call the "transport layer"  
> artificially takes three functions (demux, flow control, and  
> operational abstraction) and lumps them together in what we  
> traditionally call "transport layer", while leaving out other  
> functions (session, presentation, etc.) and artificially deeming them  
> to be "not transport layer". Such artificial distinctions do not help  
> guide our networking design thought processes in useful ways.

   I believe we all agree that the current "definition" of "transport"
layer isn't working well.

> For our purposes here, there are three relevant groupings:
> 
> C. Application/Presentation/Transport/etc.
> B. IP
> A. Datalink/Hardware/etc.
> 
> In group (A) there are differences due to inherent differences in the  
> underlying hardware.
> The purpose of IP (group B) is to homogenize away those hardware  
> differences and present a uniform service model.

   IP layer does pretty well at harmonizing hardware differences; thus,
its definition is helpful.

> In group (C) there are intentional differences due to the different  
> requirements of different applications.
> 
> The point is that the differences in group (C) are *intentional*.  
> Different applications have different requirements. The whole *point*  
> of having different transport protocols is that they offer different  
> operating semantics -- e.g. UDP preserves message boundaries; TCP  
> does not.

   I wouldn't agree that's the "whole point".

   An "ideal" transport layer, IMHO, would contain enough options to
suit the needs of a very wide variety of applications. (No, I'm not
holding my breath either.)

   But any transport layer we define today should harmonize differences
in lower layers. For example:

- we know 802.16 is coming. The IP layer can't hide all its quirks.

- we know the IPv4-IPv6 shift is coming -- and will take a rather long
  time. The IP address formats are wildly incompatible, and there are
  other characteristics of IPv6 routing which will become apparent.

- we know that TCP depends upon some quirks of IPv4 that were never
  actually specified as behaviors of that layer.

- we know that DNS is getting long in the tooth, and suffers from poor
  configurations as well as occasional unfriendly attacks. We don't
  know how successful DNSSEC deployment may (ever) be.

- we know that IPsec deployment is a rocky road.

- we know that IP layer routing could use some security tweaks.

> I think that when we denote a certain application protocol using a  
> name like "foobar", that name has to encompass the complete package  
> of everything the application uses, requires, and assumes, from the  
> IP layer up.

   It would certainly be good to define such requirements; but I think
it extremely short-sighted to expect application writers to maintain
separate versions of their applications for all combinations of issues
I listed above.

   Does the application desire separate streams to the same remote
process? Shouldn't it be able to specify this instead of opening
multiple transport-layer connections?

   Does the application want to know when a possibly-mobile remote
process changes its routing? Shouldn't it be able to specify this
rather than constantly tear down and restart connections?

   Does the application want to maintain a "connection" to a remote
process while connectivity is lost for a possibly extended period?
Shouldn't it be able to specify this, rather than try to remember
enough to restore state when a "similar" connection is made later?

   Et cetera...

> Tempting as it is to think of networking as a set of tinker-toy
> components that can be just plugged together in whatever order we
> feel like, in the real world software is a lot more brittle than
> that.

   But should it be?

   Is there _really_ any reason we shouldn't want an application to
just run -- for years at a time?

   IMHO, what breaks applications is all too often having to deal
with underlying network changes that we didn't bother to abstract
away.

> I'm all in favour of applications negotiating capabilities  
> and requirements, but that has to be done by the applications, and  
> done carefully, with thorough testing. Thinking that we can solve  
> this problem by just enumerating all the permutations in the DNS  
> seems naive to me.

   Thinking we can solve much of anything by adding permutations to
DNS is naive, IMHO...

--
John Leslie <john@jlc.net>
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae