Sent from my iPad
On 14 Jan 2014, at 23:05,"l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk"
<l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk> wrote:
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.
Lloyd,
With the significant improvements in h/w design methodology
and the addressing of the s/w bugs that Curtis and I have been
explaining to you, it would seem that the fundamental
paper that underpins your argument is without credibility, and
by your own admission below, it seems that there are no
valid statistics for the current Internet to sustain your case.
Unless you can show that the misdelivery rate from this effect
exceeds the current rather high unwanted packet rate that
hosts need to fend off, I cannot see any basis to maintain
your assertion that the c/s is required in tunnel applications
to protect the rest of the net.
With regard to the IPv4, the IP checksum, which, in all router
implementations I have seen, is checked at every hop and
only incrementally changed, there is surely adequate
protection against misdelivery to another endpoint.
With regard to IPv6, I find it difficult to understand that
the threat is of any significance given that absence of demand
for the retrofit of a similar checksum in MPLS to protect
PEs and prevent the incorrect egress of traffic.
What is the error rate in modern h/w and network systems?
No-one measures end-to-end misdelivery. No-one knows.
The upper bound is the packet loss rate less the congestion
discard rate. Do we have a figure for that?
Stewart
Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Stewart Bryant [stbryant(_at_)cisco(_dot_)com]
Sent: 14 January 2014 22:46
To: Wesley Eddy; Wood L Dr (Electronic
Eng);curtis(_at_)ipv6(_dot_)occnc(_dot_)com
Cc:gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk;mpls(_at_)ietf(_dot_)org;ietf(_at_)ietf(_dot_)org;randy(_at_)psg(_dot_)com;tsvwg(_at_)ietf(_dot_)org;jnc(_at_)mit(_dot_)edu;lisp(_at_)ietf(_dot_)org
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(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk 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
.
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html