Hi Gorry, I think you've hit the points well below. Adding and explicit "UDP checksum of zero is invalid" to the next revision should help things. Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Gorry Fairhurst > Sent: Friday, October 08, 2010 5:48 AM > To: dccp@xxxxxxxx > Subject: Re: [udp-encap rev2] discussion/comments > > See comments in line... > > On 08/10/2010 09:54, L.Wood@xxxxxxxxxxxx wrote: > > Andrew, > > > > a few points: > > > > - turning off the UDP checksum (which also acts as a necessary > demultiplexing > > at-the-right-endpoint check) has repeatedly proven to be a very bad > idea. > > Subtle NFS corruption etc. See the end-to-end papers. Saying 'well, > > the higher layers will obviously check their work in this case' > > hasn't worked out so well in practice. > > > I support mandating the checksum for transports. Although I agree this > has implications for lightweight systems and this we should always be > mindful about. > > > - That UDP encap overhead is trivial, even on smaller systems. > > Leaving out TCP - big code space win. Removing UDP as well and giving > up > > going through many firewalls/NATs - not so great a tradeoff for the > smaller > > space saved. (I've worked with endhosts that only speak UDP.) > > > Agree with Lloyd. > > We could have mandated an inner DCCP checksum for IPv4 and a UDP > checksum for IPv6 (already mandated for all end-to-end IPv6 transports). > There would be differences then between v4 and v6 which seems to me to > be a poor side-effect. But I do not think *IS* the issue the WG were > tasked to solve (see below). > > > - that UDP can now compute a checksum only on its headers, using a > > redundant length field to indicate checksum coverage length. It's > called > > UDP-Lite - this would carry DCCP without having to checksum the > payload twice. > > Unfortunately, Lite was eventually given a different protocol number, > > rather than being a simple upgrade to UDP, because pretty much all > existing > > implementations relied on the 'wrong' UDP length field and preferred > > it over the IP length field, so the redundant field wasn't really > > redundant after all. > > > Agree; To me UDP_lite would be good - but if we are talking about > solving a deploymeent issue for DCCP, it offers no help at this time. > > > So you can argue for DCCP over UDP-Lite as more efficient from a > checksum > > coverage computation viewpoint, in that both DCCP and UDP-Lite can > protect > > (checksum) just their headers, and leave payload checking to the > application. > > But UDP-Lite has the same problems with NAT and firewalls that DCCP > does, > > as it's an unusual protocol number... (And Lite's pass-errored- > > stuff-to-application focus is pretty useless over any MAC layer > checking > > its own payloads against channel errors, e.g. Ethernet's CRC32c frame > check.) > > > > I'm really looking forward to reading a possible specification for > > the UDP-Lite in UDP encap, where handwaving will be used to justify > > turning off the outer UDP checksum for IPv4! > > > No comment. > > > L. > > > > Lloyd Wood > > L.Wood@xxxxxxxxxxxx > > http://sat-net.com/L.Wood > > > > As I recall DCCP wants a solution that can be deployed. Like-it or > hate-it, the Internet contains traffic shapers, load balancers, NAT, > NAPT, etc - all of which (I suggest) should support DCCP, but currently > don't. They do know how to change UDP checksums to reflect the header > changes in the IP and UDP protocol headers - so if we want DCCP to > traverse these real-world middleboxes right now, we need to use a UDP > checksum. In future, they xould currently do the more complicated > processing required to inspect the paylaod of a UDP datagram and fix a > DCCP checksum (why would they? how would they know the packet was a DCCP > packet?). I'd prefer anyway that DCCP is more widely used and that > middlebox people implement RFC 5597 (It's not much different to what > they already implement). > > Gorry > > > On 8 Oct 2010, at 09:19, Andrew Lentvorski wrote: > > > >> On 10/5/10 12:32 PM, Phelan, Tom wrote: > >> > >>> [TomP] I am very against doing the checksum calculation twice, once > for > >>> UDP and then again for DCCP. In my opinion, implementations should > know > >>> which encapsulation is being used. > >> > >> I hope I'm missing something, but ... > >> > >> I'm *very* against usage-context sensitive protocol definitions. > >> > >> Why should my DCCP stack need to know that it got wrapped in UDP > >> somewhere along the line? > >> > >> If somebody wants to only generate one checksum, it is better that they > >> punt the UDP checksum. > >> > >> Besides, my (admittedly old) copy of Stevens indicates that UDP > >> checksums are optional. Therefore, any random system routing the UDP > >> packets can legally smash that checksum, no? > >> > >> In addition, on an embedded system, I have to carry the code around to > >> generate both a UDP checksum *and* a DCCP checksum if I have a DCCP > >> stack in order to comply with this encap. If the DCCP checksum is > >> extant, I can punt the UDP checksum code. > >> > >> That's not being very nice to the people running small systems. So, > for > >> example, if I want to run DCCP on a system with lwIP, I'm going to have > >> to go find the SO_NO_CHECK option in lwIP to enable UDP checksums, kick > >> it on, recompile *lwIP* (and reprogram my RTOS or similar), eat the > code > >> space, and redeploy my *OS*--all just for DCCP. That's not going to > win > >> many converts. > >> > >> Whereas, if you don't force the UDP checksum on people, they can deploy > >> DCCP directly to application space without having to bash the lwIP/RTOS > >> that's already installed. > >> > >> I would also like to point out, that it is *less* compute intensive for > >> DCCP to compute a checksum only on its headers (that is still in the > >> spec, right?) than for UDP to have to compute a checksum on the entire > >> DCCP packet. > >> > >> So, given that all I can see are disadvantages, what am I missing? > What > >> are the advantages to using the UDP checksum? > >> > >> -a > > > > > > > > > > > > > >
