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

Sally Floyd <sallyfloyd@mac.com> Wed, 27 June 2007 23:45 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3hCv-0005tb-D6; Wed, 27 Jun 2007 19:45:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3hCu-0005tP-Ab for tcpm@ietf.org; Wed, 27 Jun 2007 19:45:56 -0400
Received: from smtpout.mac.com ([17.250.248.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3hCG-0008ID-1v for tcpm@ietf.org; Wed, 27 Jun 2007 19:45:56 -0400
Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id l5RNj20o004523; Wed, 27 Jun 2007 16:45:02 -0700 (PDT)
Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5RNix1h008806; Wed, 27 Jun 2007 16:45:00 -0700 (PDT)
In-Reply-To: <46770412.8090307@psc.edu>
References: <b1e79256f18fcb6f81ae417fde5ca646@mac.com> <46770412.8090307@psc.edu>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <46ffa03042528d92a9ea2875e1764b19@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard?
Date: Wed, 27 Jun 2007 16:44:45 -0700
To: John Heffner <jheffner@psc.edu>
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: Murari Sridharan <muraris@microsoft.com>, Jitu Padhye <padhye@microsoft.com>, tcpm <tcpm@ietf.org>, Mark Handley <M.Handley@cs.ucl.ac.uk>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

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

------------------------------------------------------------------

The current Proposed Standard behavior in this area, from Section
4.1 of RFC 2581, says that TCP "SHOULD" reduce cwnd to the initial
window after an idle period exceeding the RTO.  RFC 2861 is
considerably more moderate than this.  Does anyone know if there
are TCP implementations out there that follow the "SHOULD" from
RFC 2581, just out of curiosity?

Is the feedback that the Congestion Window Validation mechanism in
RFC 2861 should be modified?  Or that CWV is useful but is just
fine to be left as Experimental?  (That would be fine by me.
Less work...)

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


Original email:

> Sally Floyd wrote:
>> This email is to ask the working group if RFC 2861 on Congestion
>> Window Validation (CWV) should be left at Experimental, or whether
>> it is time to start the process of moving it to Proposed Standard.
>> RFC 2861, from June 2000, "describes a simple modification to TCP's
>> congestion control algorithms to decay the congestion window cwnd
>> after the transition from a sufficiently-long application-limited
>> period, while using the slow-start threshold ssthresh to save
>> information about the previous value of the congestion window.
>> RFC 2861 also recommends that "the TCP sender should not increase
>> the congestion window when the TCP sender has been application-limited
>> (and therefore has not fully used the current congestion window)".
>> My understanding is that CWV has been included in Linux since
>> Linux 2.4, but that it is not included in Microsoft.
>> Are there any experience reports about CWV (positive or negative),
>> or experience reports of problems (or the absence of problems) for
>> TCP connections without CWV?  Or are there other opinions about
>> whether it is time to start the process of moving RFC 2861 to
>> Proposed Standard?  Any feedback would be welcome.


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