Stewart, your 'I'm not in tunnel applications' suggests you've misunderstood the argument here. The point is not to protect the tunnel traffic (which can quite happily checksum itself), it is to protect everything else on the network from misdelivery. It's not the tunnel application, it's every application sharing the internet with the tunnel which has UDP checksums turned off. See all of RFC 6936 section 3.1. Tunnel is fine, sideeffects of misdelivery do not affect tunnel. And in IPv4 and IPv6, the pseudo-header checksum built into TCP and UDP is all we have. IPv6 deliberately copied v4 here. > What is the error rate in modern h/w and network systems? No-one measures end-to-end misdelivery. No-one knows. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@xxxxxxxxx] Sent: 14 January 2014 22:46 To: Wesley Eddy; Wood L Dr (Electronic Eng); curtis@xxxxxxxxxxxxxx Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; randy@xxxxxxx; tsvwg@xxxxxxxx; jnc@xxxxxxx; lisp@xxxxxxxx Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) On 14/01/2014 22:07, Wesley Eddy wrote: > On 1/14/2014 4:57 PM, l.wood@xxxxxxxxxxxx wrote: >> I don't think sayng 'oh, that error source is no longer a problem' disproves >> Stone's overall point about undetected errors, though the >> examples he uses from the technology of the day are necessarily >> dated. Dismissing the overall point because the examples use obsolete >> technology is throwing the baby out with the bathwater; a host-to-host >> error check catches things that intermediate checks cannot. >> >> Measuring error rates across end-to-end Internet traffic is something that has >> not received much attention , as error detection is not >> instrumented well - hence citing Stone's published work, in the absence >> of awareness of anything newer (and as high profile/immediately recognisable >> as sigcomm) in the area. >> > > +1 ... the message in the paper is applicable to layered systems > and internetworks in general. Changes in the link technology > since then don't invalidate it, especially since we know that > the technology not only changes rapidly, but also is always > growing in diverse directions, such that there things almost > universally true today may be turned on their heads tomorrow. > > Designs for stacking layers need to follow solid general > principles in order to be robust to changes (above and below). > Note that it is not only the link layer technology that has moved on, the signal integrity of the h/w at all stages of the design and implementation process has moved on. Can we agree that the statistics in the paper are discredited? If not, why not? What is the error rate in modern h/w and network systems? Is this significant in the application under consideration? Finally if we are really concerned that we do actually need a c/s (I am not in tunnel applications) why are we still happy to use what is frankly a pathetic check in modern terms? Why for example are we not moving to something like the Fletcher 64 bit c/s? Stewart