Re: [tcpm] Exceeding value in MSS option?

Out of my head, most current router operating systems support MSS clamping, and albeit I have no measurement data, I’d be surprised if that router feature is not widely used.

If the network clamps the MSS, it may not really matter if a connection endpoint picks an MSS larger than the value enforced by the network. But I am not sure if draft-ietf-lwig-tcp-constrained-node-networks-11 should discuss MSS clamping as technique. It is not at all specific to constrained devices.

Michael

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Gorry Fairhurst
Sent: Tuesday, October 20, 2020 5:03 PM
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: tcpm@ietf.org Extensions <tcpm@ietf.org>
Subject: Re: [tcpm] Exceeding value in MSS option?

See below...

On 20 Oct 2020, at 13:56, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com<mailto:mirja.kuehlewind@ericsson.com>> wrote:

Hi Martin, hi Gorry,

I think Gorry’s paper does indicate that at least for MSS, there are middleboxes that add this option. However, I don’t think there is evidence that there is a general problem about middlebox adding option (rather than removing them). I also reviewed the draft in tsv-art review and given that they say it’s actually not recommended and should only be done with care, I thought that text is okay. However, I guess there is room to improve the wording and explain a bit better, when and if this might be consider or not.

Mirja

Right. This approach is not great for evolution of the size in future, but this use of MSS to restrict packet size has not broken the Internet - far from it, it is probably the way connections currently avoid black holes. I suspect that any operator adding overhead will be aware of what they are doing, and that If they do MSS clamping they will adjust that if needed, or just configure a bigger MTU within their network segment.

Gorry

From: tcpm <tcpm-bounces@ietf.org<mailto:tcpm-bounces@ietf.org>> on behalf of Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>>
Date: Tuesday, 20. October 2020 at 11:13
To: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>, "tcpm@ietf.org Extensions<mailto:tcpm@ietf.org%20Extensions>" <tcpm@ietf.org<mailto:tcpm@ietf.org>>
Subject: Re: [tcpm] Exceeding value in MSS option?

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

tcpm@ietf.org<mailto:tcpm@ietf.org>

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<https://protect2.fireeye.com/v1/url?k=c964a91f-97c41371-c964e984-866038973a15-4c538007322d8392&q=1&e=8b72cbc2-683a-493b-a075-c9df067b88f7&u=https%3A%2F%2Ftma.ifip.org%2F2018%2Fwp-content%2Fuploads%2Fsites%2F3%2F2018%2F06%2Ftma2018_paper57.pdf>

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

Gorry