Re: [tcpm] Exceeding value in MSS option?

[Markku Kojo <[e-mail]>]

Hi,

see inline.

On Wed, 21 Oct 2020, Michael Scharf 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.
>
> But I still wonder whether we should keep a reference to RFC 6691, given that this topic has repeatedly caused confusion.
>
>>  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?

That's much better but I would say it even more strongly because this is 
MUST in RFC 1122 as pointed out earlier:

" ...
   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].
   ..."

->

" ...
   Note that
   TCP implementations MUST consume payload space
   instead of increasing datagram size when including IP or TCP options
   in an IP packet to be sent [RFC1122, RFC6691].
   ..."

OR (if RFC 2119 language is not used in this doc, and currently it is not 
used although section 2 exists):

" ...
   Note that
   it is required 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 [RFC1122, RFC6691].
   ..."

BR,

/Markku

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