Subject: Re: 'Slow-Start Restart after Idle' draft

From: Vernon Schryver <[email-masked]>
Date: Fri, 23 Oct 1998 12:12:16 -0600 (MDT)

> From: Venkat Padmanabhan <[email-masked]>

> ...
> I disagree with your statement that it is irrelevant whether there are 
> 0 hops or 10 hops. I agree with Joe Touch that having a 0-hop path (that should
> actually be "1-hop", but oh well...) is significant. I believe slow
> start should be skipped *only if* there is a 0-hop path between source and
> destination. Such a path is fundamentally different from all other paths
> in the following sense: if the MAC protocol grants the source host access
> to the channel, then the source "owns" the channel for a certain length
> of time. During this period, the source can be sure that the entire
> bandwidth of the channel is exclusively available to it, so there is
> no reason to probe for bandwidth a la slow-start. 

That model of how a LAN works sounds nice and fits the textbooks, but it
is neither entirely accurate nor relevant.  To see its accuracy, consider
CSMA/CD during the first slot-time.  It would be relevant just in case
such ownership affected how TCP works.  The reason for a go-fast mode has
nothing to do with property ownership, but purely with whether TCP/IP runs
faster.  (For TCP, "speed" covers "reliability".)

> The situation is entirely different when a connection traverses more than 
> one link (i.e., 1-hop or greater, according to the terminology for this
> discussion thread) no matter what the RTT is.

Everything is different from everything else, but the only differences
that matter are those that matter.  The difference that matters here is
that paths (not merely LANs) without significant congestion from other
hosts or potential congestion at bottlenecks do not benefit and are harmed
by slow-start, slow-restart, and the 2:1 ACK:segment ratio.  That fact is
the only justification for a fast mode.  That harm has nothing to do with
whether the link is 0/1 or 100 hops long, although it is far less likely
with more hops.  That characterization, "without significant congestion
or bottlenecks," is independent of whether some MAC protocol has granted
some ownership, even where that notion makes sense.

Note that:
    - congestion that ought to be managed with slow-start can happen
       on the sending side of a host-LAN-host link when the sending host
       is much faster than the LAN, and the host-LAN interface is one of
       those bottlenecks.  For a fun, try a bunch of simultaneous ttcp or
       netperf sessions on a fast host using 100BASE-T or FDDI, 60 KByte
       default TCP windows, and less than 1 MByte of output buffering in
       the driver.  For that matter, try it with one ttcp session using
       a MByte TCP window but less than 1 MB drive buffering.

    - a path without congestion or bottlenecks but that has errors is also
       harmed by slow-(re)start.  If you know that there is no other
       traffic and no bottlenecks, then you do NOT want to shrink the
       transmit window when you detect loss, because you know the loss
       had nothing to do with congestion.

    - router and bridges (and therefore hops) tend to go together with
       connecting slower and faster links in a path, and so with
       bottlenecks that need slow-start.  So hops, if they were detectable,
       would be a reasonable go-fast mode switch.  But hops) are not
       detectable (briges, except by looking at the RTT and then only
       much of the time.

    - what I'm saying now is slightly contrary to my claim this morning
       about satellite links.  A link with 500 ms RTT, that is carrying
       only one TCP/IP connection, and where all of the links in the path
       have the same bit rate does not want slow-(re)start or any other
       congestion avoidance mechanism, because there is no congestion to
       avoid (expcept perhaps at the sending host).

       However, a satellite link or any path with an RTT larger than about
       10 ms is likely to involve multiple segments including at least
       one where the bit rate is far slower than the bit rate at the
       sending host, and so a bottleneck that wants slow-start.

> Of course, 0-hop doesn't necessarily mean that it is
> okay to skip slow-start (i.e., we can't make an *if and only if* assertion).
> A slow receiver could get overwhelmed by a fast sender and drop packets.
> This is not fundametally different from congestion at an intermediate
> router in the multi-hop case.

A slow receiver is less likely to produce a fast RTT, and in any case,
had better not be dropping any TCP/IP packets.  That's what the TCP
window is all about.  However, there is the sending-host case.

> Therefore, there is a need for a per-host flag to indicate whether
> or not it is okay to skip slow-start (as Sam Manthorpe suggests).
> Of course, how these flags would be set is an open issue.

A per-host, purely manual, violate-the-standard-and-go-fast flag is always
possible, but is also outside the scope of of a standard.

Vernon Schryver    [email-masked]

---

From: Venkat Padmanabhan <[email-masked]>
Date: Fri, 23 Oct 1998 12:03:04 -0700

> faster.  (For TCP, "speed" covers "reliability".)

I guess I am entirely missing what you are saying here...

What I am saying is that in the 0-hop case, the regulation would be
done by the MAC. TCP needn't. TCP would still have a flow-control
window, though, but that's a function of the socket buffer size set
by applications, and hence orthogonal.

> some ownership, even where that notion makes sense.

I can't contest the validity of the tautologies in the first sentence ;-)

I was saying that there is *fundamental* difference between 0-hop and
n-hop where n > 0. It is dangerous to assume that a path is lightly
loaded. Since the path is presumably shared by many hosts and no one
host has a complete picture of the load imposed by other hosts, what
is lightly loaded at one instant could be heavily loaded at another
(for instance, due to "flash crowds"). In other words, it is difficult
(in fact, fundametally flawed) to characterize a path as being
"without significant congestion or bottlenecks" given the shared
nature of the network. 

However, in the 0-hop case, the MAC protocol
gives a host exclusive access to the channel for a certain length of
time. There is no competition above the MAC layer, except between
multiple connections on a host. Of course, there is competition
at the MAC layer and we would want it to be resolved fairly, etc.,
but that is an orthogonal issue.

As a performance optimization one certainly might want to take advantage
of times when a multi-hop network is in fact lightly loaded. But I believe such
aggressive use of the network must happen only in conjunction with 
mechanisms that avoid/alleviate disaster when the "lightly loaded"
assumption is incorrect. One possible mechanism is priority dropping
which I discuss in the "TCP fast start" chapter of my thesis:
http://www.cs.berkeley.edu/~padmanab/phd-thesis.html

>        a MByte TCP window but less than 1 MB drive buffering.

Sure, it can happen at the sender. I've seen it several times on a
WaveLAN network. It can happen at the receiver, too.

> possible, but is also outside the scope of of a standard.

A per-host flag need not be set manually. A host can learn from past 
experience and set it automatically.

-Venkat