[e2e] Is a non-TCP solution dead?

[Cannara]

Hans,

I agree with your statements, with the following exceptions:

1) We do not know the network layer underlying any flow with certainty.  Thus,
for instance, your ATM example is quite possibly relevant to many paths that
one might use.  We simply don't know when rate controls are being employed
below TCP without having access to, and analysis of, the paths.  So, we lose
performance by not taking advantage of good network layer congestion
management, because TCP assumes error loss is congestion loss. This is
particularly true in private networks.

2) The existence of other flows is indeed ipmportant, for the simple reason
that they can influence congestion at some switching nodes along the path. In
these discussions, people have been concerned with wireless, in particular,
generating loss from error and congestion interactions.  Since TCP currently
has no idea why loss occurs, a parallel, unreliable flow through a congested
node can easily disrupt a 'reliable' TCP flow's performance.

The bottom line is that some of TCP's flow-control complexity is unnecessary
in end-end transport management, but was added in years ago to try to protect
network-layer nodes from disaster.  Since we now have more unreliable parallel
flows and more unreliable paths, as in wireless, to contend with, TCP is an
inadequate solution to a growing network-layer problem.

Alex

Hans Kruse wrote:
> 
> There is a fundamental disconnect/problem in this discussion, as I see it:
> 
> TCP is either very good or a nuisance, DEPENDING ON the assumptions you can
> make about the underlying network.  Contrary to repeated statements, most
> of the current network infrastructure does not do congestion control at
> intermediate nodes.  An application that is deployed without being able to
> make assumptions about the underlying network, and that requires reliable
> delivery (i.e. re-transmits), needs to make rate-limit its transmission in
> the absence of back-pressure from the network.
> 
> IF you can make more specific assumptions about the network with regard to
> congestion control, then TCP's action are superfluous and/or a nuisance.
> For example, if stations always established an ATM VC before sending the
> TCP SYN, TCP would not require slow-start nor congestion control.  But that
> is a very different network from the one we call the Internet now.
> 
> On a side note, TCP's share of the overall network traffic is not a
> relevant measure.  TCP's share of reliable transports flows is;  I would
> venture that the vast majority of non-TCP traffic is real-time unreliable
> flow, which does not create congestion problems due to retransmissions.
> 
> --On Wednesday, April 09, 2003 09:01 -0700 Cannara <cannara at attglobal.net>
> wrote:
> 
> > Love that touch Lloyd -- it's required on some other lists, believe it or
> > not.  By the way, you know we can assess how any alternate transport might
> > improve over TCP by noting what's been removed -- if slow-start isn't
> > there, then it's relatively easy to estimate; if delayed-ack is gone,
> > ditto; same for other changes to backoff.  In fact, someone could simply
> > recompile NS with items commented out, unless it's too spaghetti like.  :]
> >
> > I'll see what I can make of an XCP/FAST comparison, as an exercise for
> > students.  Might be good.
> 
> Hans Kruse, Associate Professor
> J. Warren McClure School of Communication Systems Management
> Adjunct Associate Professor of Electrical Engineering and Computer Science
> Ohio University, Athens, OH, 45701
> 740-593-4891 voice, 740-593-4889 fax