- NANOG - lists.nanog.org

Re: It Continues...Sprint Is played the fool...
by Sean Donelan 14 Jan '97

14 Jan '97

> Suggested reading are the rules and regulations for common carriers, Good idea, I suggest everyone do this, or at least have a chat with their company lawyer. Common carrier laws and regulations are a bit dry, but I read a bunch of them dating back to the 1600's. All based on English Common Law, because my non-english language skills are lacking. > Joe does not like the fact that I call him on the > phone, so he calls my local phone operator and have > them to block my phone for outgoing calls. > > My mother is about to die and she needs and ambulance, > but the phone does not work. This is a strawman argument. Barry didn't asked Sprint to block all outgoing communication, or calls to emergency services, only calls to his network number. A different division of Sprint will block calls between certain telephone numbers at the request of the subscriber. They advertise the blocking as a 'feature.' So this isn't a company-wide policy, but rather a division-level business decision. Unless your mother is in the habit of calling Software Tool & Die for ambulances, I don't see the relevance. > All ISP's should have as a policy to move packets, or for some > atlest try to move packets as close they can to the destination. You could have this policy for your ISP. But it isn't a requirement of common carriers when the carrier knows the addressee refused the shipment. An old example, you hire a livery to ship horse manure to my house. I tell the livery I don't want the horse manure delivered to my house. The livery does not have to move the horse manure as close as they can to my front door after I tell the livery I refuse to accept it. A more modern US-centric example, attach a US Post Office Business Reply mailer on a brick, and you will discover the post office will discard the brick as close as they can to the origin. This does not mean you can't mail bricks through the mail. One man mailed an entire house to Alaska, one brick at a time, and the post office delivered them. But if the Post Office knew the addressee had refused to accept the bricks in Alaska, the Post Office isn't required to ship the bricks to Alaska just so the shipment could be refused. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Questions about Internet Packet Losses
by Vern Paxson 14 Jan '97

14 Jan '97

> Yeah, but I doubt that they're in the majority. Recent stats indicate that > about 9% of the packets out there are using an MSS of 512. Another 1% are > using an MSS of 256. Only 6% are using 536, and 7% are using 1460. This > indicates to me that there are a whole lot of broken boxes out there still. I believe you're misinterpreting the numbers. The raw data for those numbers (if they're the same ones I'm thinking of) indicate that 9% of the packets had a 512 byte *payload*. This is quite different than whether the TCP sending the packet had a 512 byte MSS, because often the TCP doesn't *have* 512 bytes to send. Crunching through the 340,000 HTTP connections in and out of LBNL last Friday, less than 10% had requests exceeding 512 bytes. Even 35% of the replies were <= 512 bytes. Toss in SYN/FIN and pure acks and you rapidly dilute the relationship between measured packet size and MSS. A much more solid way to estimate MSS's is to look at MSS options in SYN packets. Rich Stevens did this in TCP/IP Illustrated Vol 3. I don't have it here at home for precise figures, but he found that the large majority of the MSS's were from a few standard sizes. He also found an immense range of bizarre values (my personal favorite: 17,520 bytes), but they were rare. All that said, at the next NANOG I'll talk about some findings from a TCP behavior study I've been doing (it's part of the packet dynamics study). One of my main findings is that independently-written (i.e., non-BSD-derived) TCP's are much more likely to have serious performance and congestion problems. Vern

3 2

Re: Questions about Internet Packet Losses
by Vadim Antonov 14 Jan '97

14 Jan '97

Bob Metcalfe <metcalfe(a)infoworld.com> wrote: >Hello, and best wishes for what's left of 1997. Now, if you would, ... Same to you :) >Is Merit's packet loss data (NetNow) credible? As always, the packet loss data doesn't always measure loss in the network. > Do packet losses in the >Internet now average between 2% and 4% daily? The congestion is definitely not distributed evenly. There are hot spots, and to my knowledge there was no any significant research on how those hot spots are distributes, what percentage of paths is affected, etc. >Is there any evidence that Internet packet losses are >trending up or down? Up. On-going backbone upgrades are simply not sufficient to keep up. >Were Merit's data correct, what would be the impact of 30% packet losses on >opening up TCP connections? Close to none. >On TCP throughput, say through a 28.8Kbps >modem? TCP throughput generally goes down the drain with that kind of packet loss. >How big a problem is HTTP's opening of so many TCP connections? HTTP is broken as designed. That "feature" actively destroys the cooperative congestion control mechanism. >Does TCP >need to operate differently than it does now when confronted routinely with >30% packet losses and quarter-second transit delays? No. TCP is self-clocking and fairly loss resistant. This is not to say there's no room for improvement, but nothing spectacular. For example, selective ACKs would help to deal with higher loss rates. 0.25 sec delays is something routine with satellite communications. TCP works just fine with that. >What is the proper >response of an IP-based protocol, like TCP, as packet losses climb? Try >harder or back off or what? That's described in 1988 article by Van Jacobson, Mike Karels et al. The answer is -- exponential backoff is sufficient to keep system stable. >How robust are various widespread TCP/IP >implementations in the face of 30% packet loss and quarter-second transit >delays? There's a lot of broken implementations (mostly in messy-dossy world). The 4.3 Reno-derived TCPs (the majority) are fairly robust. >Is the Internet's sometimes bogging down due mainly to packet losses or >busy servers or what, or does the Internet not bog down? The most annoying problem is not packet loss, it's routing stability. >What fraction of Internet traffic still goes through public exchange points >and therefore sees these kinds of packet losses? What fraction of Internet >traffic originates and terminates within a single ISP? 70% or so packets cross exchange points. That's empirical figure based on hypothesis that rate of content providers to consumers is about constant for all backbone ISPs. There's no difference between public and private exchanges in terms of dealing with congestion. So mentioning _public_ part is a bit misguided. >Where is the data on packet losses experienced by traffic that does not go >through public exchange points? I guess there's no reliable data. In fact, there's no theory on how to collect that data. For example, average, variance, and other traditional statistical instruments are useless when you attempt to measure fractal traffic. You end up with meaningless results -- for example, interarrival time variance is infinite; average rates over similar intervals may differ by orders of magnitude even when nothing changed, etc, etc. In other words -- if anybody pretends to know what's going on he's a charlatan. >If 30% loss impacts are noticeable, what should be done to eliminate the >losses or reduce their impacts on Web performance and reliability? a) put more fibers into the ground b) build better routers (want to invest?) c) connect those routers to that fiber. There's no hard physical limit on the capacity of the network which can be built with available electronics. There are at least six orders of magnitude of the growth which can be handled just by throwing money at the problem. The QoS, tag switching and other today's buzzwords are only marginal improvements at best. The only real solution always was and will be: more bandwidth. >Are packet losses due mainly to transient queue buffer overflows of user >traffic or to discards by overburdened routing processors or something else? Mostly buffer overflows. >What does Merit mean when they say that some of these losses are >intentional because of settlement issues? They may be looking for some libel lawsuits if they would care to substantiate the claim. >Are ISPs cooperating >intelligently in the carriage of Internet traffic, or are ISPs competing >destructively, to the detriment of them and their customers? I do not think any of them would kill the hen laying golden eggs. The reality is that backbone ISPs are starting to turn out new customers. There's always a lot of noise from those who just don't get TANSTAAFL, though. >Any help you can offer on these questions would be appreciated. You're welcome. Particularly it that would help to bring more reality into press reports. --vadim

3 2

Re: Questions about Internet Packet Losses
by Vadim Antonov 14 Jan '97

14 Jan '97

> The 4.3 Reno-derived TCPs (the majority) are fairly robust. >Yeah, but I doubt that they're in the majority. Recent stats indicate that >about 9% of the packets out there are using an MSS of 512. Another 1% are >using an MSS of 256. Only 6% are using 536, and 7% are using 1460. This >indicates to me that there are a whole lot of broken boxes out there still. I'm wondering why. The easiest way to implement TCP stack always was to pull the pieces off BSD code. Even oldest MS-DOS TCPs (like Phil Karn's KA9Q) are essentially that. --vadim

1 0

Re: E.E. Times?
by Nick Hilliard 13 Jan '97

13 Jan '97

> Has anyone heard of E.E. Times that did a piece on the Internet and blamed > Cisco routers for all the bottlenecks? They quote www.ra.net/statistics and > www.academ.com/nanog as well as Craig Lebowitz and Fred Baker. I have a > locally translated copy but I would be interested in seeing the original. > > It's on their web site if you wanna dig for it. A very sad article... The URL is http://www.techweb.com/se/directlink.cgi?EET19970106S0051. The first paragraph really sets the tone for the rest of the article: : A report by a federally funded networking research group here suggests : that severe Internet congestion might be linked to "routing instability," : wherein heavy traffic emanating from routers bogs down the public network. : The researchers further claim to have turned up evidence that Internet : autonomous systems supplied by the dominant maker of routers, Cisco : Systems Inc., have inherent router flaws that may exacerbate the problem. The comment at the end is pretty good, too: : Cisco routers might have IP-compatibility problems These people ought to stick to roads and bridges. Nick

4 3

RE: withdrawal propagation (was E.E. Times?)
by ccotton＠ttl.pactel.com 13 Jan '97

13 Jan '97

>>> OK, I've read the article, and it's not very good. The author doesn't >>> understand the terminology. ... or the basic technology. Listen to CNET radio's interview with the author (http://www.news.com/Radio/index.html, Monday 1/6/97 edition) about 19+ minutes into the recording. Chase

1 0

Re: withdrawal propagation (was E.E. Times?)
by William Allen Simpson 13 Jan '97

13 Jan '97

> From: randy(a)psg.com (Randy Bush) > > "William Allen Simpson" <wsimpson(a)greendragon.com> > > An implementation that propagates _extra_ withdrawals shouldn't _hide_ > > behind "standards compliant". In fact, I don't think _is_ either > > "valid" or "standards compliant". There is no standard that says "send > > extra BGP withdrawals for routes that you are not currently announcing". > > It was just a bug in the implementation. > > Nice to know you understand the cause well enough to assign blame. Mind > telling us all what it is? > Looking carefully at what I wrote, I do not see anything about "cause", only the validity (and standards compliance) of an implementation that displays this "effect". Obviously, I made the assumption that these effects were the results of an implementation, rather than a fabrication or a figment of Craig's imagination. Such a buggy implementation would receive "blame", and a fix would be expected. Perhaps there is some disagreement as to the existence of the phenomenon? Randy, do you disagree that there are routers: - sending more BGP withdrawals than announcements? - sending BGP withdrawals for routes that they have not announced? - passing along withdrawals from other routers' announcements seen on other interfaces, even though those routes are not announced by this router? That was my understanding of the effect, and Craig's use of the word "extra". If I am in error, please publically correct my understanding in detail, giving all the facts upon which you rely. Also, please give a reference (section and paragraph) where these phenomenon are specified as "valid" in one of our "standards". Thank you. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

withdrawal propagation (was E.E. Times?)
by William Allen Simpson 13 Jan '97

13 Jan '97

> From: Craig Labovitz <labovit(a)merit.edu> > * there are an awful lot of withdraw/announcements out there > * we don't know were they are comming from, and no, it is not Cisco's fault > * some valid, and standards-compliant vendor implementation decisions are > contributing a small fraction of extra withdraws (yes, Cisco is one of > these vendors, but there are probably others) You know, Craig, sometimes you are just too nice. If "we don't know were they are comming from" [sic], you don't know whether it is or is not Cisco's fault. Why bend over backwards to give such public deference? An implementation that propagates _extra_ withdrawals shouldn't _hide_ behind "standards compliant". In fact, I don't think _is_ either "valid" or "standards compliant". There is no standard that says "send extra BGP withdrawals for routes that you are not currently announcing". It was just a bug in the implementation. We _know_ (based on your research and Cisco's admission) that Cisco's have/had this bug. Therefore, it is at least Cisco's "fault". We don't _know_ (no research, no admissions) that anybody else has this problem; so the value of "probably" is more like "possibly". In any case, it "probably" doesn't matter if anybody else has the problem, since Cisco controls 85+% of the backbone market. > * there are differing opinions on how much of a problem all of this extra > withdraws pose for Internet There are always differing opinions about the Internet. Heck, there are differing opinions about whether the Internet is even useful. We are not looking at or talking about opinions, we are looking at operational facts. And the facts indicate that the duplicate withdrawals comprise a large fraction of the BGP traffic, which in turn comprises a large fraction of the backbone router CPU usage. > * even though it is not clear there was/is a significant problem, vendors > (Cisco) have created fixes to limit some of the extraneous routing > information Have these fixes been universally deployed yet? What release? And how did that affect the withdrawals seen in the overall backbone? > * a recently noticed 30-second periodicity to updates tends to suggest a > systematic problem in the infrastructure. What you mean is a systematic problem in the routing code, or maybe even in the BGP specification. Occam's Razor. The "infrastructure" is something else entirely. The number of wires in the routing mesh are not likely to have any effect on the periodicity of the traffic sent over them. > This 30 second periodicity > occurs with both widthraws and announcements (and seems independent of > the extra withdraw problem). Yes, so why are we talking about it in the same breath (paragraph)? Wouldn't it be better to acknowledge it as a separate issue? And how is the research on the source of the problem progressing? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

RE: E.E. Times?
by Chris A. Icide 13 Jan '97

13 Jan '97

Actually, I have to admit, the following was my favorite line, considering the copyright at the end of the article.... Quotes from the article follow: CMP Media's Prinz said his operation uses "Bay Networks' routers, and we have no issues with them. In fact, they don't have such a thing as a withdraw announcement." "Copyright (r) 1997 CMP Media Inc." <------ quote, and not a copyright on this mail. Chris A. Icide Nap.Net

2 1

Re: tcg and cerf.net?
by Scott Bradner 13 Jan '97

13 Jan '97

Comm Week 23/12/96 said that Teleport Communications Group closed a deal to buy CERFnet

2 1