Re: [tcpm] Exceeding value in MSS option?

[Gorry Fairhurst <[e-mail]>]

On 19/10/2020 20:22, Martin Duke wrote:
> Hello tcpm,
>
> Section 4.2.2.6 of RFC 1122 
> <https://datatracker.ietf.org/doc/html/rfc1122#page-85> 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 
> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-11#section-4.1.1> 
> 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?
>
> 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

Hi Martin,

While a server advertising a restricted MSS clearly reduces the TCP 
packet size, it seems to me to be a rather poor solution to the problem 
in general, and only works for TCP.

If  it wants to say some advices, I think the IETF needs to consider 
current practice and the implications of this. I suspect the practice of 
clamping the IPv6 MSS at the server is already quite common, especially 
in IPv6 servers offering web content. MSS Clamping on-path is also 
common, but anyway I see some servers advertise an MSS much lower than 
permitted by the MTU. For example, see the section on MSS handling here:

https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf

This might be because of the reasons for this are cited in RFC8900.

Gorry