Subject: Comments on SLOW...

From: Jamshid Mahdavi <[email-masked]>
Date: 07 Apr 2000 16:11:08 -0700

Note:  This is recommending a lot of changes.  I'm happy to write all
of the text, but I wanted to run the ideas through the group first for
comments before doing all of the writing.

--J

===================================================================

I propose that we do some reorganization on section 2 of SLOW.  In
particular, 2.3 and 2.5 kind of go together, so let's move the MTU
stuff before the TCP stuff, and make it section 2.3.

I like the MTU content, but I'd change the phrase "effectively turns
off delayed ACKs".  We TCP weenies tend to equate delayed ACK with ACK
per 2 packets.  We should be more clear, and say that 

    using an MTU that takes more than 200 milliseconds to transmit
    will cause an ACK to be generated for every segment, rather than
    one per two segments as is normal with most TCP implementations.

(The gripe is that the ACKs are still delayed by 200 msec, so they
should still be called delayed ACKs.  They do still have the other
benefits of delaying, such as piggybacking ACKs and data).

Under the TCP sections, I suggest that we reorganize them as follows:

2.4  Interactions with TCP Congestion Avoidance [RFC2581]

*  Keep the description of CA.  

*  However, the current description confuses rate and window.  I'd
   like to clarify this.

*  Explain the issues of increased RTT due to queuing in this section
   also.

2.4.1  Recommendations for network elements connected to SLOW links.

*  This section would include a recommendation to limit queue lengths
   to reasonable values.  This would be minimum of 3 segments (for
   FR/FR), and a maximum based on the delay imposed by the queue.  For
   single user links (i.e. modems), a bandwidth-delay product is
   probably a good value to recommend here.

*  Also include recommendations for RED and ECN in this section.
   Interesting question is whether RED makes sense for single user
   devices (modem pools) with short queues.  This might actually be a
   case where drop-tail is better (or at least equivalent -- how long
   does it take to go over the max threshold if the queue is only 3
   packets?)

2.4.2  Recommendations for TCP implementations

*  In general, I'd say that the management responsibility for SLOW
   connections should be applied in the following order:
   1.  Network queues
   2.  TCP sender
   3.  TCP receiver
   4.  Applications and Sysadmins

   In other words, whatever performance problems we have should first
   be fixed by making the network more suitable to work correctly with
   a standard TCP implementation.  These are the queuing
   recommendations above.

   If the network is messed up (i.e. has queues that can fill up to 3
   seconds worth of data, or no queues at all), the sender TCP is in
   the best position to detect this and compensate for it.  Senders
   can also implement shared congestion state and persistent
   connections which would help because you could remember certain
   parameters from one flow to the next.

   If all of these fail, then the receiver TCP might try to do
   something using the receiver window.

   We should try to make it clear that, only as an absolute last ditch
   effort, should applications or operating system parameters be used
   to make improvements to performance.

My logic on this last point is as follows.  First, applications might
actually have a legitimate application reason to want to set socket
buffer sizes.  This is the actual point in having settable socket
buffer sizes: managing system resources, *not* managing network
resources.  So I don't like the recommendation that apps not set
socket buffers.

Second, a single system default is a pretty poor way to manage network
resources.  For example, if I dial in on my laptop sometimes, and
other times hook up via a 100 Mb/s PC card, what should I do?  Do I
use different values when my modem negotiates 56 kb/s than when it
negotiates 9.6 kb/s?

If we are going to recommend that OS vendors add a "dialup/LAN"
dialog, lets instead recommend that they actually fix the problem in a
way that handles both the SLOW and FAST needs.  This means changes in
the TCP stack along the same lines as autotuning, but more
specificly targetted to this problem.

Section 3: Summary of recommendations.

   Implementors should consider the possibility that a host will be
   directly connected to a low-speed link when choosing default TCP
   receive window sizes.

We should replace this recommendation with something suitable based on
the above discussion.

   Application developers should consider the possibility that an
   application will be used on a host that is directly connected to a
   low-speed link, before increasing the TCP receive window size beyond
   the default for TCP connections used by this application.

I'd replace this with:

   Application developers should not attempt to manually manage
   network bandwidth using socket buffer sizes.  Only in very rare
   circumstances will an application actually know both the bandwidth
   and delay of a path and be able to choose a suitably low (or high)
   value for the socket buffer size to obtain good network
   performance.

I'd also be in favor of recommending the implementation of new APIs
which let applications find out information about how much network
bandwidth (or window or RTT or whatnot) is currently available from
the transport layer.  Perhaps something like what ecm is toying
with...

--Jamshid