Subject: Re: dynamic rwin adjustments

From: Vernon Schryver <[email-masked]>
Date: Tue, 23 Feb 1999 17:43:17 -0700 (MST)

> From: "Eric A. Hall" <[email-masked]>

> Anybody doing anything with dynamic default rwin sizes? Like, if the
> incoming connection request is from a local node whose RTT is already
> known, set window for X? or, probably better, if connection request is
> from a remote system with no defined route, assume high-latency RTT
> equal to previous remote connections and set rwin to X?

Why bother, at least using tactics like those?  The RTT is only one of
the parameters for computing the window size that gives you maximum
throughput.  Given an RTT of 1 msec, 100 msec or 100 usec, what window
would you recommend?  Besides, for many TCP connections, more throughput
than can be provided by 4 MSS worth of window is useless and will not and
cannot be used.

What resources are you conserving or better utilizing by adjusting your
window?  Why not just advertise a 2 GByte receive window for all
connections?  I can see two reasons, worst case buffer space used and the
buffer space in the router(s) just beyond the big bottleneck(s) in the
path.  You care about the former because it's not nice to have a packet
arrive when you have nowhere to put it.  You might care about the latter,
because having a lot of bytes waiting in that router means they're more
likely to be discarded or to contribute to latency on your other incoming
traffic.   However, the other guy's congestion window is also supposed to
worry about such things.

The paper recently mentioned here about dynamically adjusting receive
windows looks interesting.  As I understand it, their idea is to adjust
receive windows based on the out-going congestion window and/or recent
receive throughput and a notion of fairness.  Their plan seems intended
to give every connection the largest window that maximizes total system
throughput, while honoring the familiar operating system notion of fairness
or at least avoiding starvation.  (I'd repeat the URL of the paper, but
I think I've lost it.)

Vernon Schryver    [email-masked]

---

From: Jamshid Mahdavi <[email-masked]>
Date: 24 Feb 1999 08:48:22 -0800

> or at least avoiding starvation.  (I'd repeat the URL of the paper, but

A couple corrections, and the URL.  The paper covers dynamic tuning of
the senders socket buffer (and hence sending window).  It is dynamic
throughout the connection, not just at startup as Eric asked in his
original email.

For receiver window, we argue that just setting the window to max (as
Vernon suggests) is just as effective as dynamically tuning.  The
reason for this is that, under normal circumstances, receivers use 
very little memory.  The data in the receive window is normally stored
in the network.  The cases where you would need the receiver memory
are when packets are dropped or when applications get behind.

Unless you tuned *very* conservatively, tuning would still probably
allow for situations where loss in the network would fill up all of
the available memory (mbufs) on the receiver.  There is perhaps a
better case for trying to protect the system from slow applications.

In either event, data in the receive queue is eligible for dropping.
This is a fairly draconian solution, but since (in most
implementations) this data is not ACKed until it is delivered to the
application, you can free up memory very simply by dropping some data
from connections which are being memory-hogs.  In our testing, we
never encountered a situation where this was necessary -- although we
didn't go out of our way to look for one, either.

Oh yes, here is the URL:

http://www.psc.edu/networking/papers/auto_abstract.html

--Jamshid