[Flent-users] IRTT UDP-lite support

Pete Heist pete at heistp.net
Sat Mar 9 11:34:17 EET 2019


> On Mar 8, 2019, at 9:31 PM, Dave Taht <dave.taht at gmail.com> wrote:
> 
> My principal desires for udp-lite support in both netperf and irtt is
> that it is a udp alternative that actually works, at least on linux
> and some forms of bsd, over ipv6, and so far as I can tell (without
> serious testing) ipv4, even through nat.
> 
> UDP port space is especially constrained in light of the rise of QUIC
> and increasingly short NAT state machine timeouts. I've seen NAT's
> lose their udp tracking in well under 30 seconds (well below the rfc),
> and for a reason!
> all the udp ports are often used up on busy nat and now CGN translators.
> 
> It is not because of it's additional support for a partial checksum
> that I favor trying to make UDP-lite more deployable.

Aha, ok! In that case I’ll put it on the list for first just supporting UDP-lite with a regular full checksum. It should be easy (said the sailor, unawares of the kraken). The partial checksum for measuring corruption can be down the road.

Regarding NAT, I appreciate the expertise here as I didn’t know running out of UDP port space was a common problem. Do you think that could cause some of your UDP loss to flent-london?

If a NAT implementation is not aware of UDP-lite, it will only differentiate it by proto number 136, meaning there could only be one UDP-lite conversation at a time. It looks like UDP-lite support made it in to nf_conntrack_proto_udp.c as of kernel 4.11, which means most consumer embedded routers won’t know about it, but then again, those devices are usually used by fewer users. If on the other hand a NAT does support UDP-lite, we get a fresh port space.

If only NAT never were, and Internet MTUs increased with the times...

Pete




More information about the Flent-users mailing list