Hi Lloyd, I'm pretty much in line with what you say here. See inline for details... Tom P. > -----Original Message----- > From: L.Wood@xxxxxxxxxxxx [mailto:L.Wood@xxxxxxxxxxxx] > Sent: Friday, October 08, 2010 4:55 AM > To: bsder@xxxxxxxxxxx > Cc: L.Wood@xxxxxxxxxxxx; Phelan, Tom; gerrit@xxxxxxxxxxxxxx; dccp@xxxxxxxx > Subject: Re: [udp-encap rev2] discussion/comments > > 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. > [TomP] Yes, and I've committed to adding "UDP checksum of zero is interpreted as invalid checksum" to the next revision. > - 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.) > > - 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. > > 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.) > [TomP] UDP-Lite would have solved some problems, but its use of a different protocol number breaks the major feature we're looking to support -- passage through existing NATs that have no knowledge of DCCP (and UDP-Lite). > 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! > > L. > > Lloyd Wood > L.Wood@xxxxxxxxxxxx > http://sat-net.com/L.Wood > > 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 > > > >
