Lloyd, At this point in time those who would know what error rates are for current technologies are likely to be people who work for transport vendors, router vendors, and operators and those are the type of people you have been arguing with. You don't really think that no one has thought about improving error rates in 15 years, right? That said, if an academic can do a direct measurement *today* the results might add something to the discussion. A paper that old adds little for this particualar topic because too much has changed. I anyone thought today's rates of undetectable errors were a problem they would be adding something more robust such as a 64 bit CRC to important link layers. [Some bandwidth would be chewed up. TCP ACK packets would get bigger. Mpps rates for "small packets" would be easier to hit. What's not to like. :-) ] Curtis In message <290E20B455C66743BE178C5C84F1240847E63346C5@xxxxxxxxxxxxxxxxxxxxxx> l.wood@xxxxxxxxxxxx writes: 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. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Stewart Bryant [stbryant@xxxxxxxxx] Sent: 14 January 2014 18:26 To: curtis@xxxxxxxxxxxxxx; Wood L Dr (Electronic Eng) Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; lisp@xxxxxxxx; david.black@xxxxxxx; randy@xxxxxxx; tsvwg@xxxxxxxx; jnc@xxxxxxx Subject: Re: [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)) I agree the paper is now obsolete. Stewart On 14/01/2014 17:06, Curtis Villamizar wrote: > Lloyd, > > Maybe you should reread the paper too before citing it as evidence. > Check the date on it. Check the cited causes of errors. > > Packet traces from 1998 and 1999 are prehaps not so relevante today, > particularly wrt error rates due to hosts, router memories, and link > error rates. Look at the cited caused of errors and realize that many > things have changed. > > The largest single error in the paper (paerhaps as high as 99.9% of > the errors) was the ACK-of-FIN bug in Windows NT. They may have fixed > that by now. Other large causes were host hardware and host software > bugs (sent bad data in the first place). > > One fifth of campus errors were caused by two hosts. This is cited as > a bug in Mac OS on Powermac 8100, fixed at the time of publication. > > A lot of host software errors are discussed, where the checksums are > sent bad and therefore will pass any router link FCS. > > Sending host hardware errors were thought to be in large part caused > by no data integrity check on host DMA transfers. I think progress > has been made on that front. You can check PCIe. It has a 32bit CRC > per lane in the link layer and retransmits on error. > > Router memory errors was thought to play a large role in the non-host > part of the error rate in the paper. Routers use ECC now. Going that > far back they didn't always have parity RAM (and sometimes ran parity > disabled to avoid parity error reloads). > > VJHC software errors? Anyone still use VJHC? Those errors should be > gone. > > IP over HDLC over T1 missed a few errors at the link layer in those > days. That could be true and occurances dependent on the providers. > In the paper that was thought to be a very small contributor. > > Both HDLC and PPP had an option for 16 bit or 32 bit FCS. Often 16 > bit was used. Some HDLC equipment could be and was configured to > count errors and send the packets on their way on the assumption that > it was better to count errors and deliver bad packets rather than > deliver no packet. Perhaps also to hide packet loss. Today all of > the link layers in use have 32 bit FCS and count and toss errored > packets. In most equipment all of the memories have ECC and all of > the buses ECC or FCS if serialized. > > It is now 14 years since that paper was published in Signcomm and 16 > years since some of the observations. Things have changed. Nice bit > of nostangia but that paper may no longer be relevant. > > Curtis > > reference - > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > > In message <290E20B455C66743BE178C5C84F1240847E63346BD@xxxxxxxxxxxxxxxxxxxxxx> > l.wood@xxxxxxxxxxxx writes: >> Curtis >> >> I suggest reading Stone's work, particularly >> ''When The CRC and TCP Checksum Disagree' >> for discussion of corruption. >> >> Particularly its conclusions: 'In the internet, that means >> we are sending large volumes of incorrect data without >> anyone noticing'. >> >> The Layer-2 check is per link, not end-to-end. That matters. >> >> The MPLS assumption is that it crosses a link with a frame >> checksum. Putting MPLS over UDP breaks that assumption. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Curtis Villamizar [curtis@xxxxxxxxxxxxxx] >> Sent: 12 January 2014 18:09 >> To: Wood L Dr (Electronic Eng) >> Cc: adrian@xxxxxxxxxxxx; randy@xxxxxxx; gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; lisp@xxxxxxxx; ietf@xxxxxxxx; david.black@xxxxxxx; jnc@xxxxxxx; tsvwg@xxxxxxxx >> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >> >> In message <290E20B455C66743BE178C5C84F1240847E63346BA@xxxxxxxxxxxxxxxxxxxxxx> >> l.wood@xxxxxxxxxxxx writes: >> >>> On nested checksums, the question is how they are nested; it's a matter >>> of scope. With a bunch of checksums checking only a payload and any >>> inner checksums like Russian Matryoshka dolls, the end-to-end argument >>> tells us that for reliable receipt of the payload, only the innermost checksum >>> matters. >>> >>> But here, we are not solely checking the payload, but information on how to >>> deliver and identify that payload - and while an outer Ethernet CRC is across >>> the last link, the UDP checksum, though weak, provides a check on the IP >>> addresses and UDP ports (via the pseudoheader check) and MPLS stack >>> from UDP/IP source to UDP/IP destination (and the payload, which is the bit >>> everyone focuses on as the performance hit as redundant and a processing >>> cost when the payload has its own check, and the bit that UDP-Lite can leave out). >>> >>> Nothing else checks that scope. The scope is wider, and affects the network >>> as a whole. Errors in these unchecked fields lead to misdirection and lead to >>> misdelivery. Or pollution of other ports. >>> >>> The MPLS assumption is that it's protected and checked by a strong link CRC like >>> Ethernet, and checked/regenerated by stack processing between hops; here, >>> in a path context, with zero UDP checksums MPLS has no checking at all. >> >> That UDP would be running over IP over Ethernet or POS or GFP or ... >> >> There is no layer-2 currently in use that does not have a robust FCS, >> generally a 32 FCS and therefore the MPLS assumption of checking at a >> lower layer is still valid. >> >> Curtis >> >> >>> "consequences for cheap hardware and for software implementations" >>> >>> I'm sorry, when was MPLS cheap? >>> >>> Lloyd Wood >>> http://about.me/lloydwood >>> ________________________________________ >>> From: Adrian Farrel [adrian@xxxxxxxxxxxx] >>> Sent: 09 January 2014 10:21 >>> To: Wood L Dr (Electronic Eng); randy@xxxxxxx >>> Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; david.black@xxxxxxx; tsvwg@xxxxxxxx; jnc@xxxxxxx; lisp@xxxxxxxx >>> Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG) >>> >>> Lloyd and Randy, >>> >>> With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, so >>> thanks for the comments. >>> >>> We did take the precaution of sending this I-D for an early TSV Directorate >>> review because of the concern about a number of factors and the overlap with >>> tsvwg work, but the review came back "clean". Of course, such a review is just >>> one person, so this conversation is good. >>> >>> Wrt zero checksum, where do you stand on nested checksums? There is some claim >>> that they represent a waste of processing. I am not convinced by that when each >>> layer is using dedicated hardware (that can presumably process checksums at line >>> speed), but I am interested in the consequences for cheap hardware and for >>> software implementations (as have been claimed to be some of the motivations for >>> this work). >>> >>> Other TSV-related issues that surely pop up are: >>> - allocation of ports for foo-in-UDP >>> - congestion control >>> >>> Please note that there are a number of I-Ds that you missed in your broad sweep >>> of "I am opposed". You should probably look at the NVGRE and VXLAN work (which I >>> think is lurking around the NVO3 working group) because that is also looking at >>> UDP encaps of a tunnelling protocol. >>> >>> Thanks, >>> Adrian >>> >>> Health warnings: >>> I am responsible AD for draft-ietf-mpls-in-udp >>> I am a co-author of the gre-in-udp draft. >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of l.wood@xxxxxxxxxxxx >>>> Sent: 09 January 2014 08:07 >>>> To: randy@xxxxxxx >>>> Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; david.black@xxxxxxx; >>>> tsvwg@xxxxxxxx; jnc@xxxxxxx; lisp@xxxxxxxx >>>> Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: >>>> [tsvwg] Milestones changed for tsvwg WG) >>>> >>>> Randy, >>>> >>>> okay, let tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get >>>> consensus on it. And then the authors can adopt that consensus for >>> mpls-in-udp, >>>> which overlaps in authorship... >>>> >>>> thanks, >>>> >>>> Lloyd Wood >>>> http://about.me/lloydwood >>>> ________________________________________ >>>> From: Randy Bush [randy@xxxxxxx] >>>> Sent: 09 January 2014 07:51 >>>> To: Wood L Dr (Electronic Eng) >>>> Cc: david.black@xxxxxxx; gorry@xxxxxxxxxxxxxx; ietf@xxxxxxxx; mpls@xxxxxxxx; >>>> jnc@xxxxxxx; lisp@xxxxxxxx; tsvwg@xxxxxxxx >>>> Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] >>>> Milestones changed for tsvwg WG) >>>> >>>>> Because they specify zero UDP checksums, >>>>> I oppose publication of draft-ietf-mpls-in-udp in its current form >>>>> I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its current >>>> form. >>>>> I oppose the IETF lisp documents. >>>> lloyd, >>>> >>>> i think i understand your position. but i disagree with preventing wg >>>> adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly >>>> see wg adoption as how we get to discuss and work on a document, not as >>>> approval of the document. as david said, i think we need to discuss it >>>> so we can decide if it should be fixed. to do so, we have to adopt it. >>>> >>>> randy > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html