Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))

[<[e-mail]>]

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
________________________________________
From: Curtis Villamizar [[e-mail]]
Sent: 15 January 2014 03:43
To: Wood L  Dr (Electronic Eng)
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]>
[e-mail] 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 [[e-mail]]
> Sent: 14 January 2014 22:46
> To: Wesley Eddy; Wood L  Dr (Electronic Eng); [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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, [e-mail] 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