On Fri, 1 Aug 1997, Eric Travis wrote:
> 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;
We are studying TCP-Sack over long delays, and I put up some interesting
plots onmy group's Web page. Look for TCP-Sack project on
http://irl.cs.ucla.edu.
The interesting plots are the ones that show cwin and ssthresh during a
ftp connection. It shows the difference between Sack and Reno when facing
congestion. I think it is quite striking, even though it is the expected
behaviour...
best regards,
- Renaud
-------
Renaud Bruyeron
Internet Research Lab, UCLA
http://irl.cs.ucla.edu
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:28 EST