Re: [tcpm] WGLC for MSS document

[David Borman <[e-mail]>]

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