[e2e] Re: [tcpm] cwnd update correction for congestion avoidance

[Michael Welzl]

Hi,

> I am probably not answering your question, but you are assuming that the 
> TCP sender will be in congestion avoidance at a very small window size 
> (the equation that you describe only applies in congestion avoidance.) 
> When cwnd is small compared to BDP, TCP should be in slow start rather 
> than in CA. With bigger cwnd, the calculation error tends to be small.

I should've been more precise: I meant small but large
enough to be in congestion avoidance, e.g. right after
fast recovery setting in. Then, the sender could update
its window to ALMOST 1 SMSS but just not enough for
sending X packets. It sends X-1 packets (causing
X-1 ACKs), and it could take up to half an RTT until
that situation changes. I haven't analyzed how severe
that really is in such a situation, but I imagine
that it's nonnegligible.


> Another note: cwnd(n+1)+= S^2/cwnd(n), does not capture the fact that 
> RTT itself is depends upon cwnd and hence on time. In my opinion, the 
> equation for mathematical analysis should be
> 
> cwnd( t+RTT(t)) = cwnd(t) + S^2/cwnd(t)
> 
> (and even that equation is simplistic at best, because it assumes that 
> RTT is deterministic and not some stochastic variable!) The ack clocking 
> mechanism of TCP takes care of random fluctuations of RTT and the 
> equation in RFC2581 is robust, but while doing mathematic analysis we 
> tend to overlook this fact.

I agree - but I wasn't going for thorough mathematical TCP
analysis, just checking where this equation is going. BTW,
since, as you say, it is common to assume equally spaced
RTTs (or "rounds"), most TCP models don't capture this effect.

Cheers,
Michael