[e2e] Is a non-TCP solution dead?

[Cannara]

Dave, you can call me as I sign -- Alex.  As Dr. Fu Cheng Peng mentioned,
something like Veno shows thought being given to correcting the shortcomings
TCP has with respect to simple errored loss.  I mentioned that the archives
for this list, if they exist, will show discussions of a number of ideas to
improve TCP.  Given that TCP was 'improved' years ago to try to solve
network-layer congestion issues, it shouldn't be surprising to find these
'fixes' now problematic in the real world we're faced with that includes
burgeoning, naturally lossy paths.

Most any commercial transport protocol from the past that did not attempt to
protect the network layer from congestion collapse will perform better that
TCP in lossy conditions, mainly because the slow-down/start-up algorithms had
a simpler, end-oriented purposes.  Allowing TCP to so deeply enter the realm
of undecidability with its added-on 'congestion-control' algorithms was a
mistake -- even more evident now as TCP traffic diminishes in relation to
other streams, and so gets/delivers far poorer service from the net than it
should.

To summarize, at least two TCP problem areas need addressing:  a) stripping
out vulnerable algorithmic code, and b) establishing a certification process
for TCP releases, perhaps as done for Open Source systems.  Without b), not
much of benefit will occur, since we've been going down the b-less path, with
some folks quoting RFCs as if that had some effect on what real users see on
their servers, deskstops and laptops.

The next issue, beyond fixing/replacing TCP, is the network layer, which is
woefully inadequate under any version of IP.

Alex

Dave Crocker wrote:
> 
> Cannara,
> 
> C> The combination of the above can make a 2MB file transfer take about 30%
> C> longer using TCP, when the loss rate is well under 1% on the path.  This is
> C> hardly good, nor evidence of a well-engineered transport.
> 
> No doubt you have comparable data on a well-engineered transport to show
> us, along with enough supporting data to demonstrate that its good
> performance under this particular scenario is not at the expense of
> other important scenarios?
> 
> Or, perhaps you actually have suggestions to make for TCP standards, to
> fix these terrible things you see?
> 
> At the least, it will help to have your discussion be very careful to
> distinguish implementation vagaries from the standards themselves.
> d/
> --
>  Dave Crocker <mailto:dcrocker at brandenburg.com>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>