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

From: John Heffner <[email-masked]>
Date: Thu, 05 Jul 2007 18:26:36 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Sally Floyd <[email-masked]>
Date: Thu, 12 Jul 2007 16:51:01 -0700

> I'm generally happy enough with RFC 2861 to support it to go to 
> Proposed Standard. But, if we do not know more (or enough) about the 
> implications of CWV than we did when RFC2861 was published, on what 
> basis do we recommend that it change status?
>
> A show of hands by folks who know that it is used and has not caused 
> complaints would also be very useful, IMHO.

Yes, I agree.

- Sally
http://www.icir.org/floyd/

---

From: Sally Floyd <[email-masked]>
Date: Thu, 12 Jul 2007 17:13:40 -0700

> 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.

Many thanks.

I assume that pacing would be a big win, with or without Congestion
Window Validation.  (With CWV, the window is not set right away to
the initial window, but is halved each RTO.)

RFC 2861 also has a paragraph at the end of Section 2 arguing that
pacing by itself would not be sufficient, without *some* reduction
of cwnd after a long idle period.  (Would one really want connections
with a cwnd of 1000 packets or more to start up with that cwnd after
an idle period of an hour?  With or pacing?  Even though there very
well *might* not be any congestion after the hour-long idle period?)

- Sally

---

From: Murari Sridharan <[email-masked]>
Date: Wed, 25 Jul 2007 08:29:58 -0700

Most modern stacks use fairly high-resolution timers to track Rtt and hence Rto which means Rto's can be small (although usually there is a minimum enforced). Given that is the case, this may be disadvantageous to applications that don't react "fast" enough. We have had code to decay cwnd on idle periods for a while now, but it has been disabled by default.

-----Original Message-----
From: Sally Floyd [mailto:[email-masked]]
Sent: Thursday, July 12, 2007 4:51 PM
To: [email-masked]
Cc: Murari Sridharan; Mark Handley; Jitu Padhye; tcpm
Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard?

Yes, I agree.

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Wed, 25 Jul 2007 11:16:12 -0700

Murari -

> Most modern stacks use fairly high-resolution timers to track Rtt and 
> hence Rto which means Rto's can be small (although usually there is a 
> minimum enforced). Given that is the case, this may be disadvantageous 
> to applications that don't react "fast" enough. We have had code to 
> decay cwnd on idle periods for a while now, but it has been disabled 
> by default.

Many thanks.
- Sally