Re: [tcpm] Request for input regarding the initial window increase

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 14 July 2011 10:05 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCD721F86F4 for <tcpm@ietfa.amsl.com>; Thu, 14 Jul 2011 03:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VkyB9F4BWiu for <tcpm@ietfa.amsl.com>; Thu, 14 Jul 2011 03:05:41 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 83B9021F855B for <tcpm@ietf.org>; Thu, 14 Jul 2011 03:05:40 -0700 (PDT)
Received: from [IPv6:2001:638:506:21:224:36ff:feef:67d1] (unknown [IPv6:2001:638:506:21:224:36ff:feef:67d1]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D1DBC1C0C0BD9; Thu, 14 Jul 2011 12:05:37 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <4E1CEC6C.7030607@mti-systems.com>
Date: Thu, 14 Jul 2011 12:05:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <22AF3C11-3973-430D-BE3D-C4B452F5E6F3@lurchi.franken.de>
References: <133D9897FB9C5E4E9DF2779DC91E947C0654B57A@SLFSNX.rcs.alcatel-research.de> <4E1CEC6C.7030607@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.1084)
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Request for input regarding the initial window increase
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2011 10:05:41 -0000

On Jul 13, 2011, at 2:53 AM, Wesley Eddy wrote:

> My personal responses as a WG participant are below:
> 
> On 7/12/2011 7:54 PM, SCHARF, Michael wrote:
>> 
>> ...
>> 
>> Question 1: Moving forward a fixed increase of the permitted TCP initial
>> congestion window (draft-ietf-tcpm-initcwnd-01)?
>> 
>> Answer 1A: Fixed upper limit to proposed standard
>> Answer 2B: Fixed upper limit to experimental
>> Answer 3C: Something else (e. g., some adaptive scheme, or no change at
>> all compared to RFC 3390); this would imply a substantial change of
>> draft-ietf-tcpm-initcwnd-01
> 
> I think B (Experimental) is a conservative approach.  I'm happy with
> that and scoping the "experiment" for general use on the Internet, with
> intent to come back and go to Proposed Standard at some point.
> Essentially, it already has close to that status ;).
> 
> 
>> Question 2: Maximum permitted initial congestion window?
>> 
>> Answer 2A: 10 MSS for an MTU of 1500 byte as suggested by
>> draft-ietf-tcpm-initcwnd-01 (other MTUs are still TBD)
>> Answer 2B: Another value (please suggest and justify)
> 
> I think 2A is appropriate due to the volume of analysis that used the
> same value (10MSS).  Anything greater hasn't been looked at as much,
> and anything lesser sacrifices the intent.
> 
> 
>> Question 3: Adaptive solution as an alternative?
>> 
>> Answer 3A: Adoption of draft-touch-tcpm-automatic-iw-01 as WG item
>> heading towards experimental
>> Answer 3B: No adoption
> 
> 
> I favor 3A, sort-of.  I would rather see it generalized to explain how the same algorithm can be used for tuning SCTP and potentially a subset of CCIDs for DCCP.  Otherwise we're begging someone to write more
> documents later in order to tell us how the same thing applies to those
> other protocols.
I really would like to see the document covering TCP, SCTP, and DCCP. The problem covers
all transports having a TCP related CC, not only TCP.

Best regards
Michael
> 
> -- 
> Wes Eddy
> MTI Systems
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>