Re: [tcpm] Exceeding value in MSS option?

[Gorry Fairhurst <[e-mail]>]

On 21/10/2020 10:20, Michael Tuexen wrote:
>> 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

+1

Gorry

>> 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
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
G. Fairhurst, School of Engineering