[e2e] Question on ssthresh setting in RFC 2581

Daniel Minder daniel.minder at informatik.uni-stuttgart.de
Tue May 16 04:46:04 PDT 2006


thank you for all your helpful comments. I think I got it :-)

Mark understood my thought experiment, which indeed was carefully

I thought of an application that sends data in bursts and nothing in
between. Otherwise, flightsize is approximately min(cwnd, rwnd) all the time
and TCP would recognise the loss by DupACKs.

Thus, the burst interval must be longer than the RTO interval. Without loss,
cwnd is set to RW (Section 4.1 RFC 2581). With loss, cwnd is set to LW _and_
ssthresh is reduced. In both cases, slowstart is performed, but the
threshold can differ widely, depending on the position of the first lost
packet in the burst. But...

> In both
> the cases you sketched it was 10 packets per RTT that caused the
> congestion.  However, in the second case we start from the notion that
> there are only 4 segments in the network.  This is wrong.

That's it! My error was that I thought 4 lost packets is less severe than 10
lost packets. Probably, this conclusion is not right. 10 packets per RTT
caused the congestion in both cases, thus the new threshold must be 10 / 2
at most. In the scenario I described, ssthresh is set to a much lower value,
which is not optimal but not wrong (like the formula I suggested)... Or as
Mark put it:

>   + This situation is conservative.  The flip side (described above) is
>     aggressive.  So, if we're going to err, this is the way to err.

And we really don't know how often this situation crops up. And yes, if it
were a high performance or high reliability application it would not rely on
TCP alone... 

Thanks again! Time to close this thread :-)


More information about the end2end-interest mailing list