Re: [tcpm] WGLC for MSS document

Xiangsong Cui <Xiangsong.Cui@huawei.com> Thu, 22 April 2010 07:22 UTC

Return-Path: <Xiangsong.Cui@huawei.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E5B3A68D0 for <tcpm@core3.amsl.com>; Thu, 22 Apr 2010 00:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.339
X-Spam-Level:
X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_50=0.001, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mwY5Y1-VpT0 for <tcpm@core3.amsl.com>; Thu, 22 Apr 2010 00:22:54 -0700 (PDT)
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B3BE23A6832 for <tcpm@ietf.org>; Thu, 22 Apr 2010 00:22:53 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L19008BFOHURA@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Apr 2010 15:22:42 +0800 (CST)
Received: from c00111037 ([10.111.16.150]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L19005XUOHT7Y@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Apr 2010 15:22:42 +0800 (CST)
Date: Thu, 22 Apr 2010 15:22:40 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
To: David Borman <david.borman@windriver.com>, tcpm@ietf.org
Message-id: <00f301cae1ec$97f94e30$96106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <C304DB494AC0C04C87C6A6E2FF5603DB47919CC610@NDJSSCC01.ndc.nasa.gov> <E1C0A48A-1A4D-4977-89A4-BEBE93605EE7@windriver.com>
Subject: Re: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Apr 2010 07:22:59 -0000

Hi David,

This is a late comment, about a typo.

3. MSS in to other RFCs

   3.1 RFC-879

      RFC-897 [RFC879] discusses the MSS option and other topics.  In
      ^^^^^^^^
It seems should be RFC-879.

Regards
Xiangsong

----- Original Message ----- 
From: "David Borman" <david.borman@windriver.com>
To: <tcpm@ietf.org>
Sent: Friday, March 26, 2010 6:59 AM
Subject: Re: [tcpm] WGLC for MSS document


> On Aug 18, 2009, at 10:38 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>
>> This note starts a 2-week Working Group Last Call on the TCPM document:
>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
>> Please send any comments to the TCPM list.  The WGLC will last until
>> September 1.
>
>
> I've finally finished updating the MSS document, and have uploaded it.
> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03
> I believe I have addressed all the comments received during the Last Call, and have done some additional changes beyond that. 
> I've been discussing the document this week at the IETF with several people, and the results of those conversations are included 
> in this new draft.
>
> Because of the time lapse, and the number of changes that I've made to the document, let's extend the
> WGLC to Thursday, April 8.
>
> Below are my responses to all the comments received during the original WGLC.
>
> -David Borman
>
>
> On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote:
>
>> 1. Needs boilerplate update (Copyright section)
>
> Done.
>> 2. IMHO in line 50: %s/to do about TCP options/to do about IP and TCP options/
>
> Done.
>> 3. Just one sentence later: "RFC-1122 [Braden89] attempted to clarify this in section 4.2.2.6, but
>> there still seems to be confusion." What is the problem here with RFC 1122? Why does RFC 1122
>> does not manage to clarify the situation. I think one or two sentence more explanation would be
>> great.
> I've removed "in section 4.2.2.6", and replaced it with a reference to a new Appendix A that
> has a more complete description of what is in RFC 1122.
>
>>
>> Alex
>
> On Aug 20, 2009, at 11:28 AM, Joe Touch wrote:
>
> ....
>> I'd like to suggest the following for this doc:
>>
>> MSSs can sometimes vary, as when used with variable compression, e.g.,
>> ROHC. The ROHC doc missed an opportunity to address the interaction of
>> variable MSS with TCP, and this might be a good place to include a
>> sentence or two on it, e.g. (IMO):
>>
>> - ---
>>
>> MSSs can sometimes vary, as when used with variable compression, e.g.,
>> ROHC [RFC5255]. It is tempting for TCP to want to advertise the largest
>> possible MSS, to support the most efficient use of compressed payloads.
>> Unfortunately, some compression schemes occasionally need to transmit
>> full headers (and thus smaller payloads) to resynchronize state at their
>> endpoint compressor/decompressors. If the largest MSS is advertised, TCP
>> retransmission may interfere with compressor resynchonization.
>>
>> As a result, when effective MSS varies, TCP SHOULD compute its
>> advertised MSS based on the smallest effective MSS.
>>
>> - ---
>>
>> Joe
>
> Added, with some rewording.
>
>
> On Aug 20, 2009, at 12:59 PM, <L.Wood@surrey.ac.uk> <L.Wood@surrey.ac.uk> wrote:
>
>> Can't TCP MSS also vary across multipath environments? Strikes me
>> that these are more common than header compression - which should
>> be advertising conservative minimum MTUs for their link interfaces.
>>
>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>
>>
>
> Ok, this one I've gone round and round on this, including adding an entire Appendix to discuss issues of which MTU value to use 
> for calculating the MSS, the history of this, issues with multi-homed hosts, non-symetric routes, and making multiple 
> recommendations, based on the context.  In the end it felt like it was getting out of control, as one thing lead to another and 
> the Appendix was getting quite large.  In the end, I deleted the Appendix, and now have just one sentence:
>
> The determination of what MTU value should be used,
> especially in the case of multihomed hosts, is beyond the scope of
> this document.
>
> This document is about clarifying that you don't include IP and TCP options when figuring out what to put in the MSS option, it is 
> not about what MTU value to use when calculating the MSS option, so it is best to just not go down that path at all.  That's not 
> to say that this isn't a topic that deserves discussion, but that it isn't the purpose of this document.
>
> On Aug 26, 2009, at 6:56 AM, Mark Allman wrote:
>
>> I am in general in favor of this document.  But, this document is sorta
>> confusing to me and so I'd vote "not ready" at the moment.
>>
>> The statement that the MSS advertisement should not include the bytes
>> consumed by options is clear, but in the explanation of that rule.
>>
>>  + I had to work through the table to figure out "length" on the y-axis
>>    was the overall packet length.
>
> Fixed.
>
>>  + I find it strange that the table is left as the sole justification
>>    without even a little bit of prose that explains it.  In fact, I
>>    would think a little prose instead of the table would make the whole
>>    thing more clear.
>>
>>  + The other thing you might note is that the MSS advertisement cannot
>>    possibly capture the right number of option bytes for every packet
>>    in a connection because options are variable (e.g., SACK).  So, even
>>    if one tries to capture option lengths in the header the length will
>>    still have to be hacked on the fly (or, you'll have to take a
>>    pessimal view of option usage as "using all of it").
>
> I've added a paragraph that says that the MSS value, being fixed, can never accurately reflect all situations of IP and TCP 
> options, because by their very nature they are variable.
>
>
> On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote:
>
>>
>> I agree with Marks's comments - in general I like the document
>> (my colleague Aaron Campbell and I asked for and offered to write)
>> something similar quite a while back).
>>
>> It is worth noting that the confusion isn't universal, at least, the
>> Linux, NetBSD, and OpenBSD people got it right (options are not
>> subtracted from the advertised MSS on these systems from our past
>> research).
>>
>> RFC2385 is wrong, though:
> ...
> I've added a reference to this issue, and pointed out that RFC 2385 is wrong.  I've also added a reference to the issue with 
> RFC-897, which mostly got the definition correct until the very last section of the document... :-)
>
> -David
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm