[e2e] Question on ssthresh setting in RFC 2581

[Detlef Bosau]

Ted Faber wrote:

>>>      
>>>
>>Hm.
>>
>>The motivation is clear: The sender must not  send more data to the 
>>network than the receiver is able / willing to accept.
>>    
>>
>
>Apparently the motivation, like the function, is not clear.
>
>Cwnd increases by roughly 1 MSS per window of data.  When calculating
>the window size to use to determine how many packets a TCP connection
>can have outstanding, the application usually does something like: cwnd
>= min(rwnd, cwnd).  Few TCP implementations, if any, make the mistake of
>overunning flow control - sending more than the receiver indicates it's
>willing to accept.
>  
>
Did I write something different? Admittedly, I misunderstood the 
motivation of RFC 2851 in the first run.
However, what I wrote in part refered by you is nothing else than what 
you perhaps read in the congavoid paper, said in many lectures and wrote 
in many papers. What´s wrong then?

>What the Note is describing is a situation in which a TCP implementation
>increments cwnd without bound and doesn't keep track of flightsize or
>uses cwnd in its congestion calculations rather than flightsize.
>  
>
I see.

That does not change anything on the remark that "flightsize" is an 
estimator - and thus might be wrong.

So, in principle, we have to argume why we prefer flightsize over cwnd.

>Here's a concrete error case.  You have a low-loss,
>nor-particularly-high-capacity network.  Let the network have enough
>capacity that rwnd packets can be in flight.  If a single TCP is on that
>network for a long time without loss - transferring a large file, for
>example - it will get into a state where the window is bounded by rwnd,
>
What´s an error with this?

>cwnd may be an order of magnitude larger than rwnd, but rwnd limits the
>number of packets actually sent so flightsize and rwnd are the same.
>That is flightsize == rwin, cwnd >> rwin (where that ">>" is a
>mathematical ">>" not a C ">>" - much, much greater than).
>  
>
Yes.

And what´s the problem?

SWND is limited by rwnd.

The question is: What happens in case of congestion?

>Now one or more other TCP sources show up.  Our hero (the long-running
>TCP) detects a loss and cuts cwnd in half (this is the error described
>in the note).  Because cwnd >> rwnd its sending rate does not change -
>the limiting factor is rwnd, not cwnd.  That's clearly an error; the
>
Why?

You may argue, that you want the sender to reduce the CWND more quickly. 
This is fine.
But the situation as described is not an error.

First of all, cwnd is not cut in the half. In case of a timeout, cwnd is 
reset to 2 segments. ssthresh is defined cwnd/2.
So if ssthresh exceeds the available path capacity, our hero will 
encounter a congestion during slow start. Right?
So you want ssthresh to converge more quickly to an appropriate value. 
This is perfectly o.k. But neigher cwnd is simply cut in the half, nor 
the situation is an "error" that would make TCP fail.

>long-time sender should reduce its measurable sending rate, not some
>internal variable.  Hence 2581 mandates using flightsize instead of cwnd
>
Excuse me, but as you know the sender´s rate is determind by the ACK 
rate - not by cwnd.
Why do you want to change a sender´s _rate_?


NB: TCP is window controled, not rate controled.


>to calculate the new cwnd, which forces a real rate reduction.
>  
>
Just again: Why do you want to touch a _rate_ ? And how does CWND affect 
the sender´s rate?

>(We don't just use rwnd because the actual available capacity may be the
>limiting factor (rwnd  > line rate * delay)).
>
We should be _extremely_ careful with delay-bandwidth products in packet 
switched, lossy networks.
As long as you deal with a lossfree line you can describe the line´s 
capacity with something like an LBP.
As soon as you have non negligible MAC latencies in the network or even 
some local recovery layer, the use of an LBP may lead to extremely wrong 
and misleading results, as we see particularly in the wireless 
literature much too often.

I´ve been wrong when I did not see the scenario given by Tim Dorcey.

That´s why I asked.

Detlef
-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937