Re: [udp-encap rev2] discussion/comments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

- 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.)

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








[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux