[e2e] What should e2e protocols know about lower layers?

[Michael B Greenwald]

   Fri, 12 Oct 2001 17:02:41 +0200
   Marcel Waldvogel <mwl at zurich.ibm.com>

   I am not sure that I see the problem. Below are two possible problem 
   statements, for which there already seem to be solutions.
   
   If the problem mostly consists of having many short-lived connections to 
   a single TCP server,  I would suggest that simply remembering the send 
   window of a previous TCP connection to the same host might be a good 
   first estimate, instead of using slow start from 0. (I understand there 
   are some implementations out there doing that already.) Or for a 
   solution at the application layer, switch to a more persistent 
   connection (as was done by HTTP).
   
   If the problem relates to having multiple connections to all kinds of 
   "local" hosts, then slow-start should take no time. On a Gigabit 
   Ethernet, a single TCP connection should saturate the network after 
   about 16 RTT (=log_2 (Rate/MSS)). Assuming typical RTT of 0.2ms, this is 
   achieved after 3ms, which doesn't look bad to me. For a 10Gbps network, 
   it would still be below 4ms to achieve saturation.
   
   Are these not the problems, or do these solutions not solve them 
   appropriately?

I think it's a bad idea to suppress congestion control even in a "local
situation".  That said, I think those solutions do not solve the
(perceived) problem appropriately for the people who want to suppress
congestion control.  Consider, for instance, a slight modification to your
example: .2ms RTT, 10Gbps network.  Imagine that two TCP flows reach some
equilibrium state; say, windows that yield rates of about 5Gpbs.  Suppose
one flow stops.  How long does it take the other to saturate the network?

If it is hard for you to get too exercised about 5Gbps being "too slow",
then consider N flows in which N-1 stop (for large enough N).
(Alternatively think about the situation where the rate is lower, but the
link is a "dedicated" connection between earth and mars.)  I'm not
endorsing these arguments, but explaining the context from which some
people argue that one should suppress congestion control in local
situations.
   
   -Marcel
   
   Christian Huitema wrote:
   
   >It should be pretty obvious that suppressing congestion control based on a 
  naïve test such as "same subnet mask" is BAD. OTOH, developers do this for a r
  eason: they are generally frustrated that TCP does not take full advantage of
   the capacity of a high speed network, especially in the case of short connec
  tions. Make no mistake, the pressure is going to increase with applications s
  uch as ISCSI and gigabit networks. 
   >
   >-- Christian Huitema
   >