Re: [Flent-users] IRTT UDP-lite support

[Dave Taht <dave.taht@gmail.com>]

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.

The partial checksum stuff I have fiddled with in things like babel
for years, and babel-hmac and babel-dtls use their own, much better
"checksumming" techniques. Voip also benefits.

There is no need to actually enable the partial checksum stuff. The
default is a full checksum.

I long ago added udp-lite tests to netperf, but they were never
accepted, and I didn't pursue them. As part of the ipv4-cleanup work
I'm currently on ( https://github.com/dtaht/unicast-extensions ) , it
seemed like a good idea to try and make a push for udp-lite working
more generally, across a new ipv4 address space and the ipv6 address
spaces.

On Fri, Mar 8, 2019 at 11:26 AM Pete Heist <pete@heistp.net> wrote:
>
> I had a tip to consider adding UDP-lite support for IRTT so I’m first thinking through how this might be helpful and how it would work.
>
> The short summary of UDP-lite is that it allows sending partially damaged packets, with an optional checksum for some bytes at the beginning of the packet (for example, for a packet header). It uses a different IP protocol number (136 instead of 6), so a socket either listens for regular UDP or UDP-lite. Otherwise, UDP-lite is semantically the same as UDP.
>
> Potentially, I could add flags to the client and server to use UDP-lite (or allow specifying a separate port for UDP-lite on the same server). I would still have UDP-lite checksum the IRTT header, because if I can’t assume I have a valid header error then checking will probably get rather complicated. So if there’s damage to the header the packet would be dropped without my knowing, but if the damage occurs in the payload I’d still receive it, then I could add an optional checksum and/or length in the header to detect corruption in the body and keep a count of corrupted packets.
>
> I’m not sure yet how well UDP-lite does through NAT.
>
> But basically, it could be used to estimate how much corruption is occurring on the path from client to server, so we can distinguish between corruption and dropped packets. Presumably this would mainly be useful for mobile networks (not WiFi though, as I think it does it’s own checksums / error correction).
>
> Thoughts?
>
>
> _______________________________________________
> Flent-users mailing list
> Flent-users@flent.org
> http://flent.org/mailman/listinfo/flent-users_flent.org



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org