Re: [tcpm] Exceeding value in MSS option?

[Michael Tuexen <[e-mail]>]

> On 21. Oct 2020, at 09:31, Scharf, Michael <[e-mail]> wrote:
> 
>>> On 20. Oct 2020, at 21:56, Scharf, Michael <Michael.Scharf@hs-
>> esslingen.de> wrote:
>>> 
>>> Hi all,
>>> 
>>> Sorry for the delayed reply. More inline...
>>> 
>>>>> On 19. Oct 2020, at 21:22, Martin Duke <[e-mail]>
>> wrote:
>>>>> 
>>>>> Hello tcpm,
>>>>> 
>>>>> Section 4.2.2.6 of RFC 1122 is pretty clear that the TCP sender MUST
>>>> consider all IP and TCP options when sizing payloads with respect to the
>>>> advertised MSS option.
>>>>> 
>>>>> I'm reviewing a document that advises that some endpoints may want to
>>>> reduce their advertised MSS on IPv6 connections in case the peer isn't
>>>> respecting that guidance. Is noncompliance with this provision a problem
>> in
>>>> the internet? Are there middleboxes injecting options that cause PMTU
>>>> drops or fragmentation?
>>>> Hi Martin,
>>>> 
>>>> the document you are reviewing says:
>>>> 
>>>>  An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
>>>>  the TCP MSS not larger than 1220 bytes.  This assumes that the remote
>>>>  sender will use no TCP options, aside from possibly the MSS option,
>>>>  which is only used in the initial TCP SYN packet.
>>>> 
>>>> The first sentence is correct. The second is not. I would suggest to simply
>>>> remove it.
>>> 
>>> The statements regarding the MSS were discussed and also rewritten many
>> times. And, sorry, apparently I have not carefully read the second sentence
>> (but, well, that sentence was also in the version of the draft that was last
>> called in TCPM...)
>>> 
>>> Given this discussion now, I agree that the second sentence could probably
>> be removed.
>>> 
>>>> Then the text says:
>>>> 
>>>>  In order to accommodate unrequested TCP options that may be used by
>>>>  some TCP implementations, a constrained device may advertise an MSS
>>>>  smaller than 1220 bytes (e.g. not larger than 1200 bytes).  Note that
>>>>  it is advised for TCP implementations to consume payload space
>>>>  instead of increasing datagram size when including IP or TCP options
>>>>  in an IP packet to be sent [RFC6691].  Therefore, the suggestion of
>>>>  advertising an MSS smaller than 1220 bytes is likely to be
>>>>  overcautious and its suitability should be considered carefully.
>>>> 
>>>> I read this as "use a smaller MSS", but this is "likely to be
>>>> overcautious and its suitability should be considered carefully."
>>>> 
>>>> I think the careful consideration is to remove this paragraph.
>>> 
>>> I am not sure if we should simply remove the whole paragraph, including
>> e.g. the reference to RFC 6691. Readers
>> The paragraph starts with:
>> 
>> In order to accommodate unrequested TCP options that may be used by
>> some TCP implementations, a constrained device may advertise an MSS
>> smaller than 1220 bytes (e.g. not larger than 1200 bytes).
>> 
>> I don't think the selection of the MSS should depend on TCP options.
>> A TCP stack may send an MSS option with a value lower then 1220, but
>> it should not do it due to any TCP options.
> 
> OK, thanks, now I actually get the point. Sorry, it was late yesterday. I agree. This is all what RFC 6691 is about.
No problem.
> 
> But I still wonder whether we should keep a reference to RFC 6691, given that this topic has repeatedly caused confusion.
That makes sense.
> 
>> That is the reason, why
>> I suggested to remove the paragraph.
> 
> What about the following shorter paragraph with three sentences:
> 
>   An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
>   the TCP MSS not larger than 1220 bytes. Note that
>   it is advised for TCP implementations to consume payload space
>   instead of increasing datagram size when including IP or TCP options
>   in an IP packet to be sent [RFC6691]. Therefore, it is not required to
>   advertise an MSS smaller than 1220 bytes in order to accommodate
>   TCP options. 
> 
> Would that be reasonable?
Sounds reasonable. Much better than the original text.

Best regards
Michael
> 
> Michael
> 
>> 
>> Best regards
>> Michael
>> 
>>> of this document may not be aware of RFC 6691, so a pointer may be
>> useful, no? Also, during the IETF last call there was a discussion on MSS
>> values significantly smaller than 1220 byte. People apparently *do* think
>> about smaller MSS values on constrained devices and this document is a
>> place to provide guidance to that community (as far as possible). This specific
>> wording came up in earlier reviews of the draft, too. Thus, the final proposal
>> "likely to be overcautious and its suitability should be considered carefully" is
>> a result of several past discussions. IMHO we should carefully consider
>> changes to this statement...
>>> 
>>> BTW, personally, I really wonder if using an MSS of 1220 byte (for IPv6)
>> indeed causes real-world problems on constrained devices, i.e., if in year
>> 2020 there is any real-world benefit of an MSS smaller than 1220 byte. But,
>> unfortunately, I don't have measurement data that would back a different
>> statement in the draft.
>>> 
>>> Michael
>>> 
>>>> Best regards
>>>> Michael
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> I have not heard of such problems, but thought I'd check with the
>>>> community to see if this precaution makes any sense at all.
>>>>> 
>>>>> Thanks,
>>>>> Martin
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>> 
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>