Re: [tcpm] WGLC for MSS document

Xiangsong Cui <> Thu, 22 April 2010 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24E5B3A68D0 for <>; Thu, 22 Apr 2010 00:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.339
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2mwY5Y1-VpT0 for <>; Thu, 22 Apr 2010 00:22:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B3BE23A6832 for <>; Thu, 22 Apr 2010 00:22:53 -0700 (PDT)
Received: from (szxga02-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Thu, 22 Apr 2010 15:22:42 +0800 (CST)
Received: from c00111037 ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <> for; Thu, 22 Apr 2010 15:22:42 +0800 (CST)
Date: Thu, 22 Apr 2010 15:22:40 +0800
From: Xiangsong Cui <>
To: David Borman <>,
Message-id: <00f301cae1ec$97f94e30$>
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: <> <>
Subject: Re: [tcpm] WGLC for MSS document
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


----- Original Message ----- 
From: "David Borman" <>
To: <>
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:
>> 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.
> 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, 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", 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, <> <> 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.
>> <><>
> 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