Re: [tcpm] WGLC for MSS document

Alexander Zimmermann <> Wed, 31 March 2010 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83F203A67B1 for <>; Wed, 31 Mar 2010 05:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DKptHSoEKh4a for <>; Wed, 31 Mar 2010 05:27:28 -0700 (PDT)
Received: from (mail-i4.informatik.RWTH-Aachen.DE []) by (Postfix) with ESMTP id 5162E3A677C for <>; Wed, 31 Mar 2010 05:27:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D8F8A57AC2; Wed, 31 Mar 2010 14:27:56 +0200 (CEST)
Received: from ([fe80::d0de:4cb1:8b0f:bd28]) by ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Wed, 31 Mar 2010 14:27:38 +0200
From: Alexander Zimmermann <>
To: David Borman <>
Thread-Topic: [tcpm] WGLC for MSS document
Thread-Index: AQHKzG7BmJAD/fL+R0Se50NJqKDMOJIL4McA
Date: Wed, 31 Mar 2010 12:27:54 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-ID: <5ddf3ab2-056f-4bc4-8516-ea9c7c8c4f67>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: " WG" <>
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: Wed, 31 Mar 2010 12:27:29 -0000

Hi David,

I like the changes you have made. Especially, the history stuff you
added (Sec 3, Appendix) is quite interesting for "young" guys like me.

However, here are some remarks. Please note that these comments are
somehow trivia. If you don't like the changes, forget about them. What
I really do not want is to block the progress.

* Sec 2, para 2: I would add references for the TCP IPv4/6
header lengths

* Appendix, last equation: I suggest to add the bounds into the equation
      576 <= EMTU_R - FixedIPhdrsize - FixedTCPhdrsize <= MTU

* Sec 4: IHO the explanation of the table is too implicit.

In the following, let's name the fields of the table like this: upper left 1,
upper right 2, lower left 3, lower right 4.

Right after the table, the draft said:

"Since the goal is to not send IP datagrams that have to be fragmented, and
packets sent with the constraints in the lower right of this grid will cause
IP fragmentation, the only way to guarantee that this doesn’t happen is for the
data sender to decrease the TCP data length by the size of the IP and TCP options"

Having read this, the following comes to my mind: I'm sitting in (4) and I want to
leave this state. The text said that only the transition to (2) is possible. However,
when I looked at the table, I thought: I can also go to (3) since the table said here
"Packets are the correct length". Bang! I got confused since the text said, the
*only* way is (2). But why? At this point I expected an explanation why (3) is a
bad idea?

Do you understand what I'm trying to say? Maybe I read the table wrong. I read it
like a transition diagram. Should I read it line by line, column by column,...?


Am 25.03.2010 um 23:59 schrieb David Borman:

> 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