Re: [tcpm] Exceeding value in MSS option?

These issues have been addressed at length in intarea and tsvwg. It wouldn’t hurt if the end systems used PLPMTUD, but fragmentation support in GRE and other tunnels is also supported. 

Ultimately, if you tunnel and cannot guarantee end system cooperation, frag/reassembly is on you. 

Joe

> On Oct 27, 2020, at 2:52 PM, Steven Sommars <stevesommarsntp@gmail.com> wrote:
> 
> 
> Much of today's mobile traffic IP traffic is GTP (GPRS Tunneling protocol) tunneled within the core network (per the 3GPP specifications).   There can be one or two back-to-back  bidirectional  tunnels between the base station and the PGW/GGSN (gateways to the Internet).   The 3GIP IP MTU requirements weren't very clear at the time, but we interpreted the requirement to be a 1500-byte subscriber IP MTU.     For those portions of the core network that used IP/ATM (AAL5), transport of a ~1540 byte tunneled packet (IP MTU + about 40 bytes for GTP/IPv4 header) was  usually provided.   [I'm using 40 bytes for simplicity, could be smaller or larger.]  Ethernet was cheaper and more readily available, so transport of 1540 byte packets was needed.  [I'll skip other headers that are often used: VLAN, MPLS, etc.]       The cellular carriers often leased IP/Ethernet transport and at times only ~1500 byte MTUs were available.  
> 
> If the IP/Ethernet transport network supports sufficiently large IP MTUs, life is simpler.   If not, how does one stuff 1540 bytes into a 1500 byte packet?   
> - Avoid core network IP fragmentation.    I'll list some of the options & their drawbacks.
>         -   Resegment TCP (e.g., proxy).    ===  many drawbacks
>         -   Fragment subscriber packet  (ignore DF bit)    ===   many drawbacks
>         -   Drop packets that would require fragmentation (PMTUD).  ===  PMTU black hole was an issue
>         -   Signal to the subscriber device that the IP MTU should be reduced.   ===   This was proposed in 3GPP starting in the late 1990's, but I don't know what happened.
>         -   Insert/Alter TCP MSS option during SYN/ACK.   ===   Not strictly legal, but it typically worked well.
> - Implement core network IP fragmentation/reassembly.   Done correctly this is undetectable by the subscriber- or server-side.   However,
>         -   Transport network bandwidth requirements increased slightly.
>         -    IP reassembly can be resource intensive.    [I've seen performance drop by over 100x when IP reassembly was needed on some older hardware.]
>         -    IP reassembly may fail.
>         -    Fragmentation and reassembly may trigger missequencing.
>  
> Is TCPM the right forum for discussing these end-to-end principle related items?   RFC3234 has a somewhat dated (2002) middlebox taxonomy.
> 
> 
> 
> 
> 
>> On Tue, Oct 27, 2020 at 10:25 AM Joseph Touch <touch@strayalpha.com> wrote:
>> So the real question is why tunneled packets didn’t trigger the same issue - isn’t it?
>> 
>> Or are you implying that tunneled traffic shouldn’t be supported?
>> 
>> There are deeper issues going on here. We should avoid being glib about how “best” to do things that shouldn’t be done in the first place.
>> 
>> Joe
>> 
>> > On Oct 26, 2020, at 11:35 PM, Frode Kileng <frodek@tele.no> wrote:
>> > 
>> > I do not defending this practice, just trying to communicate their rationale and that there may be other more important fights out there. But I do understand that operators are cautious as I've seen an example of how fragmentation triggered an anti-DDoS feature in a firewall causing traffic from a large number of mobiles to halt.
>> > 
>> > Frode
>> > 
>> > On 26/10/2020 17:55, Joe Touch wrote:
>> >> Given how many of us are using VPNs, it’s a shame they don’t work without this.  I guess users of those nets have to shut down their Skypes and other services over VPNs, because, according to you, it doesn’t work.
>> >> 
>> >> Joe
>> >> 
>> >>> On Oct 26, 2020, at 8:46 AM, Frode Kileng <frodek@tele.no> wrote:
>> >>> 
>> >>> On 26/10/2020 15:24, Joe Touch wrote:
>> >>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>> >>>>>> On 26. Oct 2020, at 08:52, Frode Kileng <frodek@tele.no> wrote:
>> >>>>>> 
>> >>>>>> 
>> >>>>>> On 23/10/2020 17:11, Joseph Touch wrote:
>> >>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng <frodek@tele.no <mailto:frodek@tele.no>> 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
>> >>> 
>> >>> 
>> > 
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm