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
