Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard?

Sally Floyd wrote:
> John -
> 
> (Apologies, as always, for the late reply.)
> 
>> There have been enough reports of performance problems with 
>> intrinsically bursty applications that an option was added to Linux to 
>> disable cwnd decay.  (It is still enabled by default.)  I'm not aware 
>> of any issues with the "not raising cwnd when application-limited" part.
> 
> I understand that bursty applications would often rather not reduce
> cwnd after an idle or application-limited periiod.  (It *might* be
> in their own interests, if it helps the flow to avoid unnecessary
> packet drops, but it *might not* be in their own interests, e.g.,
> if that flow doesn't receive any packet drops when bursting after
> an idle period.
> 
> But the following question also matters:
> 
> (1) What about when there are N possibly-bursty flows sharing the
> same congested link?  Are there any reports about whether the *N
> flows* do better when all flows use CWV, or whether they do better
> when none of them use CWV, and none of them reduce cwnd after an
> idle period?
> 
> (If there is no congestion, I would expect that the N flows do
> better without CWV.   If there *is* congestion, I would expect that
> the N flows in general do better *with* CWV, as opposed to not
> reducing cwnd after idle periods.  But it is not something that one
> could tell from reports from individual users...)

This agrees with my intuition, for what it's worth. :)  I'm not aware of 
any experiments along these lines.  I'm also really interested in how 
much difference pacing out bursts after an idle period might make.

Thanks,
   -John

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm