[e2e] First rule of networking: don't make end-to-end promises you

[Cannara]

Ok David, if you want to be literal, I misspoke, I should have said:

"Transports can't hide anything but perhaps loss, which will necessarily incur
a delivery time penalty."  I'm sure everyone here understands that basic
reality.  

   At 08:05 PM 4/23/2004, Cannara wrote:
   >Transports can't hide anything but perhaps loss.

   They can't hide loss - without introducing undesirable latency. 

Now, that's an interesting adjective: "undesirable".  Since one clear
objective an application has for use of a transport is getting data surely
from one end to the other, latency under loss is more desirable than loss
alone.  All latency is undesirable, which is exactly the reason why TCP's
introduction of unnecessary latency from loss, delayed ACK, uncorrected
timeouts, etc. is a concern to me, and to folks who actually depend on TCP/IP
in the real world.

On UDP traffic being "open loop".  You want to say something above it will
close some loop.  Sure it will, as do most applications, but at longer latency
penalties than if it were handled by UDP (and the network beneath), which is
what ECN offers.  So your remark is really not consistent with your abhorrence
of latency.  It's also inconsistent with your statements about congestion
avoidance needing to operate as quickly as possible to ahve a successful
management system.  I agree with those concerns.  

TCP as is, unfortunately provides less than it could and the defensive
bureaucratic responses to suggestions for improvement then leave UDP, etc.
open and in need of higher-latency, higher-layer assistance, which you say is
ok, but which then violates your concern for minimizing control latency.  It
can't be had both ways.  

Mentioning Little's obvious theorem reminds us of the possibilities for
congestion prediction, as needed for ECN, from the interior of the network,
not at the ends.  I agree.  That's very different from plopping something else
on top of UDP and hoping it can do something useful without ECN.

Speech, video and so on are indeed managed at the ends, but they have no real
choice.  With ECN-like information added by the router(s) that know Little
well, they could certainly do better.

The point of all this is that we all agree congestion avoidance is important
to do, and transport delivery is important to do as well.  The problem, as
stated many emails ago, remains that current TCP stacks do a poorer job of
delivering data than they could -- at least because they've been saddled with
congestion avoidance without good information about true congestion.

Alex



"David P. Reed" wrote:
> 
> At 07:29 PM 4/23/2004, Cannara wrote:
> >Dropping packets is
> >always how router programmers must manage queues under excessive load, so
> >those packets should fairly come from all flows.
> 
> And they do.   But that's not managing congestion.   Managing congestion is
> done by the high level protocols.
> 
> You seem to think that UDP-based protocols are open loop.   UDP is not a
> complete protocol - it is a means to allow other (closed loop) transport
> protocols to be developed (such as RTP or Gnutella) in the Internet
> architecture, the job of congestion control is pushed to the edges, as it
> should be, since there is no way that a router can understand how to manage
> congestion in a way that takes into account the application semantics (for
> protocols like "digital fountains" or like variable quality speech, or
> overlay networks that select routes based on measured quality, the response
> to congestion may be to change coding, take alternate actions that shift
> load, etc. - all of them servo off of congestion indication, which is
> pretty robustly detected by Little's Theorem/lemma, which is that queue
> length rises non-linearly with load/capacity).