In message
<290E20B455C66743BE178C5C84F1240847E63346C7(_at_)EXMB01CMS(_dot_)surrey(_dot_)ac(_dot_)uk>
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk writes:
That's robustness _for the tunnelled traffic_.
Not for anything else sharing the network - that hasn't been
instrumented and measured.
Lloyd Wood
http://about.me/lloydwood
The reason that MPLS and PWE3 are successfully deployed is that this
traffic is carried over "well-managed networks" as RFC 6936 puts it.
If a UDP and IP encapsulation is added, then nothing changes.
If the UDP encapsulation occurs on a lower end router, it is likely
that the whole packet is available on which to perform a checksum. On
a really low end router the checksum is likely to be done in software.
If it occurs on a high end router then the part of the hardware that
can today modify checksums only, doesn't even have access to the
packet to do a checksum and put it into the front of the packet.
There are two reasons for this.
1. A lot of high end routers split off the top 128-256 bytes and
send it to a decision engine which can call for header
modifications. The rest of the packet takes another path and is
later concatonated before sending out. This works fine for
checksum modifications but does not work for creating a new
checksum.
2. A lot of high end hardware, particularly hardware intended for
high end enterprise and data centers, uses a technique called
"cut-through". The first 128-256 bytes go to a decision engine
and get processed before the packet has been entirely received.
The decision and header modifications are done and if there is
no standing output queue, the header starts going out before all
of the packet has been received. This is done to reduce
latency. In these implementations if the incoming FCS is bad,
an outgoing runt packet occurs.
In the second case the UDP header is sent before the bytes over which
the UDP header is computed are received. That is a consequence of
putting the UDP checksum before the data. L2 encapsulation put the
FCS after the data for this reason.
So what you are asking, a UDP checksum on a fresh new encapsulation is
impossible for some hardware. [ps - thanks to an offline discussion
with Joel Halpern for bringing this up.]
Perhaps we need a new UDP with a robust FCS at the back of the
packet, but without that making a UDP checksum manditory for MPLS over
UDP is guarenteed to be ignored in some deployments and with no
adverse consequences. Is that what we want?
Perhaps there can be discussion added to the draft to indicate why a
UDP checksum is desirable and why in some circumstances it may be
impossible to generate or difficult to check. This along with a
SHOULD use a UDP checksum might be the best course of action.
Curtis
________________________________________
From: Curtis Villamizar [curtis(_at_)ipv6(_dot_)occnc(_dot_)com]
Sent: 15 January 2014 03:43
To: Wood L Dr (Electronic Eng)
Cc: stbryant(_at_)cisco(_dot_)com; wes(_at_)mti-systems(_dot_)com;
curtis(_at_)ipv6(_dot_)occnc(_dot_)com;
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))
Lloyd,
The part about RFC 6936 section 3.1 most relevant might be:
There is extensive experience with deployments using tunnel
protocols in well-managed networks (e.g., corporate networks and
service provider core networks). This has shown the robustness of
methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS
that do not employ a transport protocol checksum and that have not
specified mechanisms to protect from corruption of the unprotected
headers (such as the VPN Identifier in MPLS). Reasons for the
robustness may include:
If the rate of undetected modified packets is extremely low in
"well-managed networks", as we beleive is the case, then UDP checksums
won't change the situration much.
So why *not* make them optional if experience has shown they are not
needed in the types of deployments we are talking about.
Curtis
In message
<290E20B455C66743BE178C5C84F1240847E63346C6(_at_)EXMB01CMS(_dot_)surrey(_dot_)ac(_dot_)uk>
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk writes:
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(_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