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 <p...@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
