[tcpm] Fwd: WGLC for MSS document

[David Borman <[e-mail]>]

Sorry, I just realized that I only sent this reply to Alexander, and not to the whole list.

			-David Borman

Begin forwarded message:

From: David Borman <[e-mail]>
Date: March 31, 2010 11:03:53 AM CDT
To: Alexander Zimmermann <[e-mail]>
Subject: Re: [tcpm] WGLC for MSS document


On Mar 31, 2010, at 7:27 AM, Alexander Zimmermann wrote:

> 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

Actually, there is a different change that I think I should make:

  network(s)".  Thus, the MSS value to be sent in an MSS option must be
  less than or equal to:

       EMTU_R - FixedIPhdrsize - FixedTCPhdrsize

s/option must be/option should be/

It is not required that the MSS value be <= the MTU of the interface, it is perfectly OK to advertise an MSS value larger than the MTU of the interface.  This is especially true for a multi-homed host with interfaces that have different MTUs.  However, deciding what MTU value to use to calculate the MSS value is not the purpose of this RFC, the purpose of this RFC is to say that when you calculate the MSS, you do not adjust it to account for IP or TCP options.  Getting into the discussion about what MTU value to use is a rat-hole that is not part of this RFC, so I don't even discuss it.  That's why this version of the document has the final sentence in section 2:

	The determination of what MTU value should be used,
	especially in the case of multi-homed hosts, is beyond the scope of
	this document.

This is also in the appendix, so it is just additional commentary that may be useful to the reader, the requirements are in the main body of the document.


> 
> * 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,...?


It isn't a state diagram, it's a grid showing the combinations of what happens if the receiver does or doesn't adjust the MSS option to account for options, and if the sender does or doesn't adjust to account for IP options.  The text says it all.  If the sender doesn't adjust for the options, then it can't be guaranteed that it won't generate packets that are too big when it inserts options.  So it should always adjust.  And since the sender is always adjusting, the receiver doesn't need to modify the value in the MSS option to account for options.

Does that make sense?
			-David


> 
> 
> Alex
> 
> 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:
>>> 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
>