Re: [tcpm] WGLC for MSS document

David Borman <dab@weston.borman.com> Tue, 13 April 2010 15:44 UTC

Return-Path: <dab@weston.borman.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 8F1C73A6B2A for <tcpm@core3.amsl.com>; Tue, 13 Apr 2010 08:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 vkrK6GFLo0mx for <tcpm@core3.amsl.com>; Tue, 13 Apr 2010 08:43:56 -0700 (PDT)
Received: from frantic.weston.borman.com (frantic-dmz.weston.borman.com [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 6FCC73A6B24 for <tcpm@ietf.org>; Tue, 13 Apr 2010 08:43:52 -0700 (PDT)
Received: from [172.25.44.3] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o3DFhfCk005490; Tue, 13 Apr 2010 10:43:42 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: David Borman <dab@weston.borman.com>
In-Reply-To: <E1C0A48A-1A4D-4977-89A4-BEBE93605EE7@windriver.com>
Date: Tue, 13 Apr 2010 10:43:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B094F64C-95A2-49B2-A4CC-E743BF5FBB7D@weston.borman.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB47919CC610@NDJSSCC01.ndc.nasa.gov> <E1C0A48A-1A4D-4977-89A4-BEBE93605EE7@windriver.com>
To: Joe Touch <touch@ISI.EDU>, L.Wood@surrey.ac.uk, Mark Allman <mallman@icir.org>, Danny McPherson <danny@tcb.net>, Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
X-Mailer: Apple Mail (2.1078)
Cc: "tcpm@ietf.org WG" <tcpm@ietf.org>
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: Tue, 13 Apr 2010 15:44:00 -0000

Hi,
I'd appreciate it of those on the To: list of this message, who made comments on the previous version of the MSS document, could reply to the mailing list whether or not you feel your comments are adequately addressed, so that we have a record of consensus.  Thanks.
			-David Borman

On Mar 25, 2010, at 5:59 PM, David Borman wrote:

> 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