Re: [tcpm] Exceeding value in MSS option?

[Frode Kileng <[e-mail]>]

On 26/10/2020 15:24, Joe Touch wrote:
>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen <[e-mail]> wrote:
>>
>>> On 26. Oct 2020, at 08:52, Frode Kileng <[e-mail]> wrote:
>>>
>>>
>>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>> Although maybe not  a "general problem",  a study of MSS middlebox manipluation in  23 European and Asian mobile networks did reveal some issues:
>>>>>>
>>>>>> - 20 of 23 networks always inserts MSS.
>>>> That IS a general problem, FWIW.
>>>>
>>>> Besides being published, it should also be reported to the operators of those networks as violating TCP specs.
>>> Do you mean as in "layering violation" or is it explicitly stated in an RFC that MSS clamping is not allowed.
>> I think we should differentiate two issues:
>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK segement.
>> (b) a middlebox which adds an MSS option, which wasn't there in the SYN/SYN-ACK segment.
> You can if you want; I do not. Both are violations of TCP processing, whose headers aren’t permitted to be altered in flight. Saying it’s for the good of the endpoints doesn’t change the issue that it should be reported and fixed as an error.
>
> If TCP is given an MSS by the other end of a connection and packets don’t get through, it can always lower the segment sizes it sends - the is what PLPMTUD does.

I think there may be other more important fights out there than 
convincing ~90% of the world mobile network operators and their vendors 
that a practice solving potential black-holing and typically improves 
performance should stop because it's a layering violation. For example 
that 2/3rd of the mobile networks I tested have a TCP Proxy and over 70% 
of such networks breaks MPTCP, TFO or ECN.


Regards

Frode Kileng