Re: HTTP 1.1 pipelining & persistent connections query

From: Eric Travis ([email protected])
Date: Fri Aug 01 1997 - 14:08:33 EDT


On Fri, 1 Aug 1997, John V. Martinez wrote:

John,

>
> Another point: in your spreadsheet, you seem to be assuming that the TCP
> window will *double* on every round-trip until it reaches 64k. This doubling
> only happens during the slow-start phase, until the window size reaches a
> certain threshold (anyone have references for what a common threshold is?
> 8k?) -- after reaching that threshold, TCP switches into congestion-avoidance
> mode, where one packet is added to the window for every N packets received,
> where N is the current window size. So it actually takes much longer to get
> all the way to a full 64K window size. :^(
>

Hopefully I'm not mistaken (or I've got to change some code), but...

My interpretation of ssthresh is that when you create the TCB, you
set ssthresh equal to the maximum possible supportable window; 64KB
if you are not scaling, something like 1GB if you are scaling. *

This way, when establishing a connection, you'll be in slow-start
until you take a loss (hopefully due to congestion); In the meantime,
if you manage to open cwnd to your socket-buffer size, this is fine,
since cwnd will then be clamped to the smaller value:

    cwnd = min(cwnd, max_send_buff);

Your send-window will be bounded by min(cwnd, rcv_wind);
    
Although there is no *guarantee* that you will achieve a sizable
cwnd regardless of how big the buffers are one the receiving end,
bailing out of slow-start prematurely due to using a poor estimate
for ssthresh is not necessarily a good idea. You end-up finishing
growth of your cwnd in congestion avoidance mode, one segment per
RTT. Not a huge problem with small RTTs, but with big RTTs...

Once you do experience a loss (again, hopefully to congestion)
 ssthresh is then reduced to:
           ssthresh = cwnd/2;

Whether or not you end-up back in slow-start again will depend on
the nature of the loss event (timeout:yes or performing fast-recovery
in response to dup-acks:no, multiple losses within a window without a
selective Ack mechanism:yes(?)) and the resulting value of cwnd;

If cwnd <= ssthresh, your in slow-start, otherwise you are in
congestion avoidance.

Upon reflect, I suppose you *could* do something like initialize
ssthresh to max_send_buff, but this appears (to me) to add unnecessary
complexity to an implementation.

If I've screwed this up, someone will correct me :o)

Eric

* (even though scaling shouldn't be interpreted as large windows
will be offered on either side - there is nothing preventing you
from scaling a window smaller than 64K);



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:28 EST