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

Salman Abdul Baset <salman@cs.columbia.edu> Fri, 15 June 2007 10:25 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 1Hz8zc-0006JA-7K; Fri, 15 Jun 2007 06:25:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8zb-0006J5-IL for tcpm@ietf.org; Fri, 15 Jun 2007 06:25:23 -0400
Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8za-00051P-8V for tcpm@ietf.org; Fri, 15 Jun 2007 06:25:23 -0400
Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5FAORQW012852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jun 2007 06:24:29 -0400 (EDT)
Date: Fri, 15 Jun 2007 06:24:27 -0400
From: Salman Abdul Baset <salman@cs.columbia.edu>
To: Jitu Padhye <padhye@microsoft.com>
Subject: RE: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard?
In-Reply-To: <FEB1DCE23809B442BBD3414023A8D6E41C251410F7@NA-EXMSG-C111.redmond.corp.microsoft.com>
Message-ID: <Pine.GSO.4.64.0706150617170.26325@play.cs.columbia.edu>
References: <b1e79256f18fcb6f81ae417fde5ca646@mac.com> <Pine.GSO.4.64.0706141750150.15874@flame.cs.columbia.edu> <FEB1DCE23809B442BBD3414023A8D6E41C251410F7@NA-EXMSG-C111.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: tcpm <tcpm@ietf.org>, Eli Brosh <elibrosh@cs.columbia.edu>, Mark Handley <M.Handley@cs.ucl.ac.uk>, Murari Sridharan <muraris@microsoft.com>
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

Consider this example:

Suppose there is a flow which sends one packet per RTT and RFC 3390 was 
inplace so initial window was four. Also, suppose there was no loss. Since 
the application was sending one packet per RTT, the cwnd should be 
adjusted to one (is this correct?) after an application limited period. Is 
this an acceptable behavior?

-s

On Thu, 14 Jun 2007, Jitu Padhye wrote:

> This concern was mentioned by Murari as well. (adding Murari to discussion).
>
> - Jitu
>
> -----Original Message-----
> From: Salman Abdul Baset [mailto:salman@cs.columbia.edu]
> Sent: Thursday, June 14, 2007 3:01 PM
> To: Sally Floyd
> Cc: tcpm; Jitu Padhye; Mark Handley; Eli Brosh
> Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard?
>
> For application limited workloads such as streaming over TCP, we have
> found that the CW validation mechanism, which decays CW for a sufficiently
> long application-limited period, can increase sensitivity to timeouts.
> -s
>
>
> On Thu, 14 Jun 2007, 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.
>>
>> - Sally
>> http://www.icir.org/floyd/
>>
>> In the spirit of doing due diligence with old Experimental RFCs...
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www1.ietf.org/mailman/listinfo/tcpm
>>
>

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