[e2e] TCP in outer space

[Alex Cannara]

Bob,

On 1), "highly successful" means what?  Delivering the best performance
one could get from the recently-available networking infrastructure? 
Providing the business-support parameters that make the current
economics of the Internet so economically important?  Or, simply, having
permeated the end-system/router space, due to applications unforeseen by
official Internet folks (e.g., WWW).  We all know the last of these is
rarely a good measure of good design, having more to do with accident of
market and subsidy.

On 2), any transport worth the name could have been kludged to address
the scary "new situations" that arose when the Internet began to grow
beyond its original design goals.  Using transport-layer software to
partially address network-layer congestion is not really something to
crow about in any case.

On 3), several suggestions have been made over some years, but largely
ignored.  Here's an old one:  make ECN truly explicit and at the network
layer, so it covers all protocol traffic -- in other words, no false
positives, which kills TCP performance.  Or, one can even try altering
existing TCP stacks in compatible ways, so that a sender knows what
packet is being acknowledged, thus reducing silly events like
unnecessary retransmissions, etc.  For this the IP ID (oops, dumped from
v6) or timestamping could be used in existing TCP fields.  The goal, of
course is not to make future TCPs do this, but to demonstrate
effectiveness in real situations, where a <1% errored loss causes a >15%
slowdown in throughput, simply because current TCP knows nothing but to
assume all losses are congestive (a poor design decision).  There have
been many suggestions, just along performance lines.

There is also a set of suggestions that have been made regarding
network-layer admission and flow management.  This is clearly counter to
the doctrine of "let the ends do it" (even if the ends aren't given
enough to do it).  Even the only partially implemented Frame-Relay
congestion control is superior to what relying on poor old TCP can
achieve.  Just because various predictions of the Internet's choking to
a halt haven't quite materialzed (ignoring the close ones), it doesn't
mean the emperor's clothes are just fine.  This "noise" has been raised
many times.  

Alex


Bob Braden wrote:
> 
> Alex,
> 
> Your remarks:
> 
> 1) ignore the evidence that the fundemental design of the Internet
>         protocols has been highly successful.
> 
>         You may disagree, but literally hundreds of people on this
>         list believe that this was not an accident, but resulted from
>         deep thought and sound design by the Internet research
>         community over many years.
> 
> 2) ignore the evidence, repeated a number of times, that the TCP/IP
>         protocol design has successfully coped with new situations
>         that were not imagined in 1979.  This include heterogeneous
>         network technologies and a huge range of dynamic performance.
> 
> 3) cite well-known examples of areas where the current design does
>         not work as well as it should.
> 
>         Here, you have three choices: (1) contribute constructive
>         technical suggestions about how to fix these problems
>         **without losing the good attributes embodied in the
>         current architectur**; or (2) claim that these particular
>         flaws are so egregious that they require that the
>         entire Internet architecture be thrown out, and then
>         **tell us what you would do instead**; or (3) stop
>         contributing noise to the list.
> 
> Bob Braden