Re: [tcpm] Exceeding value in MSS option?

Hi, Martin,

> On Oct 19, 2020, at 1:50 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Hi Joe,
> 
> I may have phrased it ambiguously but I understand the intent of 1122/6691 as you describe it.

RFC6691 was written to clear up the ambiguity and conflicting info in other docs.

> IOAM does add IPv6 options at times, although it should scrub them before it leaves the domain. 

That is NOT OK. 

I don’t know why its not very clear that this is incorrect, but just to be clear:

	No subdomain should increase the size of a packet UNLESS it can GUARANTEE that it supports *all types of* MTUs that are equivalently LARGER than the minimums required as well as those reported outside the domain.

I.e., let’s say the domain adds 20 bytes. Then it CANNOT use equipment that supports only 1280B path MTUs and 1500B reassembly MTUs; it needs to have equipment throughout that supports at least 1300B path MTUs and 1520B reassembly MTUs.

Unless the subdomain has those guarantees, it can’t increase packet sizes. Even then, it’s playing with space the endpoints “own” (e.g., of the limits of IPv4 or TCP option space), and NO subdomain mods can make the increased packet size work.

Overall, this is a VERY BAD IDEA and should NOT be endorsed by the IETF in any way, shape, or form - including experimentally.

Joe

> 
> Thanks
> Martin
> 
> On Mon, Oct 19, 2020 at 12:44 PM Joseph Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
> To be more clear:
> 
> The MSS value in the TCP option reflects the FIXED headers only.
> 
> The sending side uses that value, together with its knowledge of options it adds, to reduce the size of the data sent to fit.
> 
> Second guessing that information is problematic; sure, when something gets through you can always try something smaller but that’s not specific to TCP or anything else.
> 
> Middleboxes should never make a packet larger under any circumstances.
> 
> Joe
> 
>> On Oct 19, 2020, at 12:37 PM, Joseph Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
>> 
>> See RFC 6691.
>> 
>> Only the fixed headers are considered, NOT the options.
>> 
>> Joe
>> 
>>> On Oct 19, 2020, at 12:22 PM, Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> 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 <https://www.ietf.org/mailman/listinfo/tcpm>
>> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm