* [Flent-users] IRTT UDP-lite support @ 2019-03-08 19:25 Pete Heist 2019-03-08 20:31 ` Dave Taht 0 siblings, 1 reply; 5+ messages in thread From: Pete Heist @ 2019-03-08 19:25 UTC (permalink / raw) To: flent-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Flent-users] IRTT UDP-lite support 2019-03-08 19:25 [Flent-users] IRTT UDP-lite support Pete Heist @ 2019-03-08 20:31 ` Dave Taht 2019-03-08 21:10 ` Dave Taht 2019-03-09 9:34 ` Pete Heist 0 siblings, 2 replies; 5+ messages in thread From: Dave Taht @ 2019-03-08 20:31 UTC (permalink / raw) To: Pete Heist; +Cc: flent-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Flent-users] IRTT UDP-lite support 2019-03-08 20:31 ` Dave Taht @ 2019-03-08 21:10 ` Dave Taht 2019-03-09 9:34 ` Pete Heist 1 sibling, 0 replies; 5+ messages in thread From: Dave Taht @ 2019-03-08 21:10 UTC (permalink / raw) To: Pete Heist; +Cc: flent-users I note your "measure corruption" thing is a cool idea, I'd not thunk of that too! _______________________________________________ Flent-users mailing list Flent-users@flent.org http://flent.org/mailman/listinfo/flent-users_flent.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Flent-users] IRTT UDP-lite support 2019-03-08 20:31 ` Dave Taht 2019-03-08 21:10 ` Dave Taht @ 2019-03-09 9:34 ` Pete Heist 2019-03-12 13:17 ` Pete Heist 1 sibling, 1 reply; 5+ messages in thread From: Pete Heist @ 2019-03-09 9:34 UTC (permalink / raw) To: Dave Taht; +Cc: flent-users > On Mar 8, 2019, at 9:31 PM, Dave Taht <dave.taht@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 _______________________________________________ Flent-users mailing list Flent-users@flent.org http://flent.org/mailman/listinfo/flent-users_flent.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Flent-users] IRTT UDP-lite support 2019-03-09 9:34 ` Pete Heist @ 2019-03-12 13:17 ` Pete Heist 0 siblings, 0 replies; 5+ messages in thread From: Pete Heist @ 2019-03-12 13:17 UTC (permalink / raw) To: Dave Taht; +Cc: flent-users [-- Attachment #1.1: Type: text/plain, Size: 1047 bytes --] > On Mar 9, 2019, at 10:34 AM, Pete Heist <pete@heistp.net> wrote: >> >> 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. Unfortunately this isn’t a one-liner in Go, as the value 0 is hardcoded for the protocol argument passed in to the socket function. It should be possible with a raw socket and making the UDP packet myself (not hard), but that requires either root privileges or cap_net_raw and looking at all proto 136 packets, which I don’t love. I’m still asking around and either way I’ll get it done at some point or another. Maybe the Go team would take a patch to add “udplite” as a new “network” argument, but I doubt it, as OS support is limited pretty much to Linux and FreeBSD. [-- Attachment #1.2: Type: text/html, Size: 3096 bytes --] [-- Attachment #2: Type: text/plain, Size: 151 bytes --] _______________________________________________ Flent-users mailing list Flent-users@flent.org http://flent.org/mailman/listinfo/flent-users_flent.org ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-03-12 13:18 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-08 19:25 [Flent-users] IRTT UDP-lite support Pete Heist 2019-03-08 20:31 ` Dave Taht 2019-03-08 21:10 ` Dave Taht 2019-03-09 9:34 ` Pete Heist 2019-03-12 13:17 ` Pete Heist
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox