Re: [tcpm] WGLC for MSS document

[Xiangsong Cui <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>
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, <[e-mail]> <[e-mail]> 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/><[e-mail]>
>>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm