[e2e] Is a non-TCP solution dead?

[Richard Carlson]

Alex;

One point I don't see in this discussion is that TCP runs over IP and IP is 
an unreliable datagram service.  Thus TCP needs control functions to 
guarantee the reliable, in-order, delivery of packets to the receiving 
application.  Is your argument that congestion control is not a reliability 
issue (dealt with at the transport level in the TCP/IP stack)?  If so, what 
functions do you see required for reliability and what functions are 
required for network health?

Rich

At 07:03 PM 3/31/03 -0800, Cannara wrote:
>I think these statements illustrate the ingrained nature of the problem:
>"
> > Optimizing transport protocols for particular link technologies may
> > seem a good thing in the short term, but it harms the future.  It's
> > hard enough to get TCP right without link-layer dependencies in there.
> > And it's harder still if you have to optimize for arbitrary
> > concatenated sequences of link-layers.
> >
> > On the other hand, if we can identify useful commonality between
> > link-layers, and if we can pass up hints to the transport to make
> > things work better without sacrificing generality or security, then
> > this seems a reasonable thing to me.  This has however proved rather
> > difficult every time it's been raised before.
>"
>The Transport should not be used to make up for behavioral variations in
>segments or links in a path.  It should be able to depend on the Network to
>provide datagram service and to handle congestion, errors, etc. on the
>Network's own.  This is why we have great efforts going on in link
>optimizations, forward error correction, etc.  None of this is a Transport
>responsibility.  It was a mistake to attempt such corrections in the TCP
>transport, even if it was alleged to avoid the embarrassments of Internet
>collapse in the '80s.
>
>Alex
>
>Mark Handley wrote:
> >
> > >If I had to choose between
> > >i)  optimise a L2 protocol for a particular transport and
> > >ii) optimise a transport protocol in order to cope with different L2
> > >protocols (not simultaneously)
> > >
> > >I would almost instinctively choose option ii)  (probably becuase I have
> > >convinced myself that if it is e2e it must be good :-)
> > >without suggesting that L2 protocols should not be "well-designed" 
> (whatever
> > >this means)
> >
> > It's not that e2e must be good - it's an evolvability issue.
> >
> > There are a vast number of end-systems out there.  To a first
> > approximation, they all speak more or less the same end-to-end
> > transport protocols, and this is necessary for interoperability.  For
> > this reason, plus the more recent proliferation of firewalls, NATs,
> > etc, it's likely that the number of end-to-end transport protocols
> > will remain small, with most of the service evolution happening above
> > the transport layer.  While transport protocol evolution does happen,
> > I'd bet money on the set of widely used transport protocols being
> > similar in ten years time.
> >
> > There are many different link technologies out there.  Almost none of
> > them are the same link technologies that were around ten years ago.
> >
> > Optimizing transport protocols for particular link technologies may
> > seem a good thing in the short term, but it harms the future.  It's
> > hard enough to get TCP right without link-layer dependencies in there.
> > And it's harder still if you have to optimize for arbitrary
> > concatenated sequences of link-layers.
> >
> > On the other hand, if we can identify useful commonality between
> > link-layers, and if we can pass up hints to the transport to make
> > things work better without sacrificing generality or security, then
> > this seems a reasonable thing to me.  This has however proved rather
> > difficult every time it's been raised before.
> >
> >  - Mark

------------------------------------

Richard A. Carlson                              e-mail: RACarlson at anl.gov
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439