[SR-Users] packets exceeding MTU size

[Alex Balashov]

> On Aug 18, 2022, at 7:33 AM, Greg Troxel <gdt at lexort.com> wrote:
> 
> 
> Alex Balashov <abalashov at evaristesys.com> writes:
> 
>> In principle, that’s right. Practically, this depends on the behaviour
>> of various intermediaries. I have seen both behaviours. In the
>> scenarios I have troubleshot, receiving only the first fragment on the
>> other side of—for example—a NAT gateway is fairly common.
> 
> It is not surprising that a broken firewall or NAT causes only the first
> fragment to show up at an OS.  It might even be more likely than not
> that a given firewall is broken :-(
> 
> It would surprise me if an OS delivered a UDP packet that contained the
> bytes in the first fragment only, and if so that's an OS bug.  So I
> would expect 99.9% the symptom to be that the packets don't arrive.

Yeah, that’s right. A lot of the real-world UDP fragmentation issues revolve around operating through NATs or otherwise stateful firewalls, however. 

For instance, as you may know, they are ubiquitous in the SDN architectures of the major public cloud providers.

> (All of this is another reason to do TCP signalling, which is able to
> negotiate MTU and not end up with IP fragmentation, but I get it that
> people have to interoperate with what the peer will do.)

There are some traditional arguments against TCP signalling in high-capacity service provider cores, mostly having to do with overhead, resource consumption, attack vectors, end-to-end latency vs TCP congestion control, etc. 

These have got less salient with increases in computing power, backbone bandwidth and overall public Internet reliability over the last two decades. Nevertheless, some of them are still persuasive in various scenarios.

On the other hand, signalling from the access layer/edge to customer endpoints across the public Internet perhaps should be exclusively TCP or TLS at this point. The near-universal NATification and CGNining of such endpoints combined with the overall trend toward increasing SIP and SDP payloads is a particularly insulting cocktail for UDP.

— Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/