Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
In message go...@erg.abdn.ac.uk writes: > > You may care to reference this to Section 2.2 of RFC 6936, which provides > some background to where UDP-Lite may help, and some of the potential > pitfalls. > > Gorry The right tool for the job but ... Expect some pushback because older hardware looks at TCP and UDP in the protocol field and then checks port numbers for ECMP load balance. That older hardware will not do this for UDP-Lite. With MPLS over UDP, only the dest port number matters and the src port number can be used like the MPLS Entropy Label. That is about the only thing that would not work in some networks with UDP-Lite. IMHO it would be advantageous to provide the option to use UDP-Lite rather than UDP with no checksum at all. The section in RFC 6936 could be cited. The limitation I mentioned could also be cited. Curtis > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > > > You do make a good point that perhaps UDP lite should be mentioned in > > MPLS over UDP as an option. > > > > Curtis > > > > > > In message > > <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> > > l.w...@surrey.ac.uk writes: > > > >> you've got the perfect application to encourage UDP lite adoption and > >> deployment here. > >> > >> Lloyd Wood > >> http://about.me/lloydwood > >> > >> From: Stewart Bryant [stbry...@cisco.com] > >> Sent: 15 January 2014 11:31 > >> To: Randy Bush > >> Cc: Wood L Dr (Electronic Eng); w...@mti-systems.com; > >> cur...@ipv6.occnc.com; go...@erg.abdn.ac.uk; m...@ietf.org; > >> i...@ietf.org; ts...@ietf.org; j...@mit.edu; lisp@ietf.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 15/01/2014 11:08, Randy Bush wrote: > >> > [ you insist on cc:ing me, so you get to endure my opinions ] > >> > > >> >> it seems that there are no valid statistics for the current Internet > >> >> to sustain your case. > >> > as we discussed privately, there seem to be no real measurements to > >> > sustain any case. this is all conjecturbation. > >> > > >> > what i do not understand is why, given the lack of solid evidence that > >> > we are in a safe space, you and others are not willing to spend a few > >> > euro cents to have a reasonable level of assurance at this layer. > >> > > >> > randy > >> Randy, > >> > >> It is not a few cents, it is likely the re-engineering of a lot > >> of silicon. > >> > >> The reason that UDP is of interest is that the on path silicon > >> knows how to process it, for example it knows how to to ECMP it. > >> > >> The reason that the UDP c/s is a problem for a tunneler is that > >> it needs to have access to the whole pkt to calculate the > >> c/s, but as you know the silicon optimised that access away > >> a long time ago. > >> > >> The alternative would be UDP-lite, but the ability of on path > >> silicon to process that as competently and as completely as it > >> processes UDP is by no means clear. > >> > >> - Stewart ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
Or perhaps UDP heavy with a FCS at the end and no checksum at all. You do make a good point that perhaps UDP lite should be mentioned in MPLS over UDP as an option. Curtis In message <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> l.w...@surrey.ac.uk writes: > you've got the perfect application to encourage UDP lite adoption and > deployment here. > > Lloyd Wood > http://about.me/lloydwood > > From: Stewart Bryant [stbry...@cisco.com] > Sent: 15 January 2014 11:31 > To: Randy Bush > Cc: Wood L Dr (Electronic Eng); w...@mti-systems.com; cur...@ipv6.occnc.com; > go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ts...@ietf.org; > j...@mit.edu; lisp@ietf.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 15/01/2014 11:08, Randy Bush wrote: > > [ you insist on cc:ing me, so you get to endure my opinions ] > > > >> it seems that there are no valid statistics for the current Internet > >> to sustain your case. > > as we discussed privately, there seem to be no real measurements to > > sustain any case. this is all conjecturbation. > > > > what i do not understand is why, given the lack of solid evidence that > > we are in a safe space, you and others are not willing to spend a few > > euro cents to have a reasonable level of assurance at this layer. > > > > randy > Randy, > > It is not a few cents, it is likely the re-engineering of a lot > of silicon. > > The reason that UDP is of interest is that the on path silicon > knows how to process it, for example it knows how to to ECMP it. > > The reason that the UDP c/s is a problem for a tunneler is that > it needs to have access to the whole pkt to calculate the > c/s, but as you know the silicon optimised that access away > a long time ago. > > The alternative would be UDP-lite, but the ability of on path > silicon to process that as competently and as completely as it > processes UDP is by no means clear. > > - Stewart ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
In message Randy Bush writes: > > [ you insist on cc:ing me, so you get to endure my opinions ] Not a problem (this time). :-) > > it seems that there are no valid statistics for the current Internet > > to sustain your case. > > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, See http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html for reasons why routers would want to avoid having to fill in a checksum. It would have been more feasible for an FCS at the end of the packet for these cases but the UDP checksum is in the front. This entire discussion is over putting in a SHOULD rather than a MUST in two places, UDP checksum and congestion control, plus deferring defining the congestion control for MPLS over UDP until deployments show a need for it. Curtis ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
You may care to reference this to Section 2.2 of RFC 6936, which provides some background to where UDP-Lite may help, and some of the potential pitfalls. Gorry > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > You do make a good point that perhaps UDP lite should be mentioned in > MPLS over UDP as an option. > > Curtis > > > In message > <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> > l.w...@surrey.ac.uk writes: > >> you've got the perfect application to encourage UDP lite adoption and >> deployment here. >> >> Lloyd Wood >> http://about.me/lloydwood >> >> From: Stewart Bryant [stbry...@cisco.com] >> Sent: 15 January 2014 11:31 >> To: Randy Bush >> Cc: Wood L Dr (Electronic Eng); w...@mti-systems.com; >> cur...@ipv6.occnc.com; go...@erg.abdn.ac.uk; m...@ietf.org; >> i...@ietf.org; ts...@ietf.org; j...@mit.edu; lisp@ietf.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 15/01/2014 11:08, Randy Bush wrote: >> > [ you insist on cc:ing me, so you get to endure my opinions ] >> > >> >> it seems that there are no valid statistics for the current Internet >> >> to sustain your case. >> > as we discussed privately, there seem to be no real measurements to >> > sustain any case. this is all conjecturbation. >> > >> > what i do not understand is why, given the lack of solid evidence that >> > we are in a safe space, you and others are not willing to spend a few >> > euro cents to have a reasonable level of assurance at this layer. >> > >> > randy >> Randy, >> >> It is not a few cents, it is likely the re-engineering of a lot >> of silicon. >> >> The reason that UDP is of interest is that the on path silicon >> knows how to process it, for example it knows how to to ECMP it. >> >> The reason that the UDP c/s is a problem for a tunneler is that >> it needs to have access to the whole pkt to calculate the >> c/s, but as you know the silicon optimised that access away >> a long time ago. >> >> The alternative would be UDP-lite, but the ability of on path >> silicon to process that as competently and as completely as it >> processes UDP is by no means clear. >> >> - Stewart > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
In message <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> l.w...@surrey.ac.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 [cur...@ipv6.occnc.com] > Sent: 15 January 2014 03:43 > To: Wood L Dr (Electronic Eng) > Cc: stbry...@cisco.com; w...@mti-systems.com; cur...@ipv6.occnc.com; > go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ra...@psg.com; > ts...@ietf.org; j...@mit.edu; lisp@ietf.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 <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> > l.w...@surrey.ac.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 v
Re: [lisp] [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 <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> l.w...@surrey.ac.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 [stbry...@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); cur...@ipv6.occnc.com > Cc: go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ra...@psg.com; > ts...@ietf.org; j...@mit.edu; lisp@ietf.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.w...@surrey.ac.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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
[ you insist on cc:ing me, so you get to endure my opinions ] > it seems that there are no valid statistics for the current Internet > to sustain your case. as we discussed privately, there seem to be no real measurements to sustain any case. this is all conjecturbation. what i do not understand is why, given the lack of solid evidence that we are in a safe space, you and others are not willing to spend a few euro cents to have a reasonable level of assurance at this layer. randy pgpg8OGG1OiPt.pgp Description: PGP signature ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
you've got the perfect application to encourage UDP lite adoption and deployment here. Lloyd Wood http://about.me/lloydwood From: Stewart Bryant [stbry...@cisco.com] Sent: 15 January 2014 11:31 To: Randy Bush Cc: Wood L Dr (Electronic Eng); w...@mti-systems.com; cur...@ipv6.occnc.com; go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ts...@ietf.org; j...@mit.edu; lisp@ietf.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 15/01/2014 11:08, Randy Bush wrote: > [ you insist on cc:ing me, so you get to endure my opinions ] > >> it seems that there are no valid statistics for the current Internet >> to sustain your case. > as we discussed privately, there seem to be no real measurements to > sustain any case. this is all conjecturbation. > > what i do not understand is why, given the lack of solid evidence that > we are in a safe space, you and others are not willing to spend a few > euro cents to have a reasonable level of assurance at this layer. > > randy Randy, It is not a few cents, it is likely the re-engineering of a lot of silicon. The reason that UDP is of interest is that the on path silicon knows how to process it, for example it knows how to to ECMP it. The reason that the UDP c/s is a problem for a tunneler is that it needs to have access to the whole pkt to calculate the c/s, but as you know the silicon optimised that access away a long time ago. The alternative would be UDP-lite, but the ability of on path silicon to process that as competently and as completely as it processes UDP is by no means clear. - Stewart ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
On 15/01/2014 11:08, Randy Bush wrote: [ you insist on cc:ing me, so you get to endure my opinions ] it seems that there are no valid statistics for the current Internet to sustain your case. as we discussed privately, there seem to be no real measurements to sustain any case. this is all conjecturbation. what i do not understand is why, given the lack of solid evidence that we are in a safe space, you and others are not willing to spend a few euro cents to have a reasonable level of assurance at this layer. randy Randy, It is not a few cents, it is likely the re-engineering of a lot of silicon. The reason that UDP is of interest is that the on path silicon knows how to process it, for example it knows how to to ECMP it. The reason that the UDP c/s is a problem for a tunneler is that it needs to have access to the whole pkt to calculate the c/s, but as you know the silicon optimised that access away a long time ago. The alternative would be UDP-lite, but the ability of on path silicon to process that as competently and as completely as it processes UDP is by no means clear. - Stewart ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
Sent from my iPad On 14 Jan 2014, at 23:05,"l.w...@surrey.ac.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 [stbry...@cisco.com] Sent: 14 January 2014 22:46 To: Wesley Eddy; Wood L Dr (Electronic Eng);cur...@ipv6.occnc.com Cc:go...@erg.abdn.ac.uk;m...@ietf.org;i...@ietf.org;ra...@psg.com;ts...@ietf.org;j...@mit.edu;lisp@ietf.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.w...@surrey.ac.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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
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 [cur...@ipv6.occnc.com] Sent: 15 January 2014 03:43 To: Wood L Dr (Electronic Eng) Cc: stbry...@cisco.com; w...@mti-systems.com; cur...@ipv6.occnc.com; go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ra...@psg.com; ts...@ietf.org; j...@mit.edu; lisp@ietf.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 <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> l.w...@surrey.ac.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 [stbry...@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); cur...@ipv6.occnc.com > Cc: go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ra...@psg.com; > ts...@ietf.org; j...@mit.edu; lisp@ietf.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.w...@surrey.ac.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 ___
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
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 [stbry...@cisco.com] Sent: 14 January 2014 22:46 To: Wesley Eddy; Wood L Dr (Electronic Eng); cur...@ipv6.occnc.com Cc: go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ra...@psg.com; ts...@ietf.org; j...@mit.edu; lisp@ietf.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.w...@surrey.ac.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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [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.w...@surrey.ac.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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG))
On 1/14/2014 4:57 PM, l.w...@surrey.ac.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). -- Wes Eddy MTI Systems ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
