- Test - lists.nanog.org

Re: Ping flooding
by Vern Paxson 12 Jul '96

12 Jul '96

> Really, consider a link where the path carrying most of the data has > a time of N and the path carrying the ack has a path 2N or N + 1/2N > You are computing an average which seems like it could be skewed based > on the path the ack takes. This doesn't matter. The key notions for TCP are (1) what's the time scale for feedback, and (2) what's the pipe size (= bandwidth-delay product). Both of these are determined by the RTT and not the one-way prop time. > Does anyone know of any papers on the effect of asymetric paths on TCP > performance? Well, I thought about this quite a bit for my end-to-end routing study (ftp://ftp.ee.lbl.gov/papers/routing.SIGCOMM.ps.Z) I really wanted to come up with some reason why asymmetric routing has serious implications for TCP performance, but wasn't able to. I guess this is a good thing, since 50% of the paths in my study were asymmetric in terms of visiting at least one different city in the two directions. 30% visited at least one different AS. Vern

2 1

Re: Routing flaps, was Re: Ping flooding
by avg＠ncube.com 12 Jul '96

12 Jul '96

>I doubt that a large provider such as Sprint or MCI or Agis or any other >major internet backbone is going to be able to hide much of their >internal route flapping, as their internal routes ARE their external routes. Well, not. BGP (exterior) table is cleanly separated from IGP table in modern backbones, so bouncing interior circuits do not generally produce routing flap visible outside (if it is not severe enough to cause partitioning). The links to exchange points and customer-access routers is another kettle of fish altogether... There are more than few ways to induce interesting instabilities in the iBGP-hack based backbones, some going as far as to produce self-feeding route oscillations. However, fascistic filtering on both IGP and BGP routing information (so they won't interact in unexpected ways) helps. >My original note was intended to reply to the specific case of using >dynamic routing to distribute routes which could just as easily be done >with static routes - I.E. where there is one and only one path to the >destination. In this case, it is sometimes desirable and necessary to >run some sort of interior routing protocol, but it is not desirable that >flaps caused by a break along the one and only one path be propogated to >the outside world, but instead the packets should be null0'd at the point >of path convergence. Yes, you can eliminate global impact of interior flaps this way; but believe me, to design a truely reliable and booletproof interior routing takes no less efforts than just place all the static routes. If you don't think so you probably never had people starting gated on their workstations just for the heck of it :) --vadim

1 0

Re: Ping flooding
by avg＠ncube.com 12 Jul '96

12 Jul '96

You need to have _very_ different path parameters to cause TCP noticeable problems (and then if one of the paths is that bad you're screwed up anyway). Most of asymmetrical paths are quite "symmetrical" parameter-wise. --vadim Vern, > (ftp://ftp.ee.lbl.gov/papers/routing.SIGCOMM.ps.Z) I really wanted to > come up with some reason why asymmetric routing has serious implications > for TCP performance, but wasn't able to. I guess this is a good thing, Maybe in a perfect world, but given that all ISPs are not created equal, it is usually the case that the two paths don't have the same latency and packet loss characteristics. Jeff

1 0

Re: On another topic ... :-)
by Sean Donelan 11 Jul '96

11 Jul '96

>>PS, Mr. Metcalfe. Reports for the old reliable telephone system show >>over the course of a year, a daily average of 30,000 US telephone customers >>are out of service for five hours. > >Source please? The ATIS network reliability council steering committee report "Keeping the Network Alive And Well: Solving the problem of cable dig-ups." <http://www.atis.org/atis.nrsc/whatsne2.htm>: >Facility outages continue to be the leading contributor to outages in the >Public Switched Network. Approximately 50% of FCC-reportable service outages >and their impact have been caused by facility outages. Roughly 33 million >customers over the past three years or 30,000 customers a day have lost >access to the Public Switched network for an average of 5 hours because of >these problems. The ATIS NRSC Facilities Solution Team was chartered to >determine the causes of these facility outages and to recommend ways to >reduce their number and impact. A copy of the Facilities Solution Team report entitled "Keeping the Network Alive and Well: Solving the Problem of Cable Dig-Ups" can be obtained by contacting ATIS on (202) 628-6380. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Ping flooding
by avg＠ncube.com 11 Jul '96

11 Jul '96

Sorry, i was unclear. It should read "forwarding return packets back to the original source". In other words -- assume that forwards and backwards paths are both crossing the same interface. That assumption is practically always valid for tail circuits. --vadim > That's once again a matter of defaults -- routers should _by > default_ discard all packets from interfaces which they won't > use for forwarding those packets back. Why? -- Jerry Anderson jerry(a)gi.net Principal Engineer (402) 436-3030 Implementation & Consulting http://www.gi.net/jerry Global Internet Network Services (formerly known as MIDnet)

2 1

Re: Ping flooding
by avg＠ncube.com 11 Jul '96

11 Jul '96

If you want to run large network you'd better think about tools to configure routers and maintain configurations. In my practice more than 70% of non-link related problems in corporate networks (and i've seen _lots_ of them) is due to unnecessary dynamic routing. Just watch some luser turing on RIP on his itty bitty terminal server or someting and causing the entire corporation to go banana. In public Internet, dynamic routing over tail links is downright antisocial. I hope i don't need to explain _that_. As an addendum to my remarks -- if you think you have complete knowledge of how you dynamically routed network behaves in case of various failures you're deceiving yourself. The distributed algorithms too often behave counterintuitively, and implementations often have subtle bugs. --vadim

1 0

Re: On another topic ... :-)
by William B. Norton 11 Jul '96

11 Jul '96

Hi! >PS, Mr. Metcalfe. Reports for the old reliable telephone system show >over the course of a year, a daily average of 30,000 US telephone customers >are out of service for five hours. Source please? Bill

1 0

Re: 10/8 announced ?
by Dave Morton 11 Jul '96

11 Jul '96

>> Hmm, is this just me , or... >> >> traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets >> 1 bigmac.netaxis.com (198.69.103.23) 214 ms 155 ms 209 ms > >... > >> >> bye,Kai >> ps: someone with access to a serious router show us this route, please... >> > >borderxx.hou.neo.net>sh ip bgp 10.0.0.0 >% Network not in table It seems our NOC did not have a filter in place although such was discussed but it seems nobody got around to actually installing it - sigh ! >I think serious providers will filter this one out :-) We do now - sorry about the mess folks. Dave > Scott >-- >smace(a)neosoft.com - KC5NUA - Scott Mace - Network Engineer - Neosoft Inc. >Any opinions expressed are mine. >

1 0

Re: On another topic ... :-)
by Sean Donelan 11 Jul '96

11 Jul '96

>Have you fully thought out what the implications are of this? >Currently the internet is not regulated. Any internet analogy of something >coming out of the FCC generally would require the internet to be >regulated.. which is something that should be though long and hard about >before jumping the gun.. The 'Internet' has been transitioning for 20 years from being owned and operated by the US government through several phases to a relatively deregulated international internetwork. But we're not completely free yet. What's this got to do with NANOG? Each section of the NSF 93-52 solicitation included an item similar to this: > o Propose and establish procedures to work with personnel > from other NAP Managers (if any), the RA, the vBNS > Provider, and regional and other attached networks to > resolve problems and to support end-to-end connectivity > and quality of service for network users Which is pretty cool because it gives us the US government's blessing to sit down with NAP managers, the RA, the vBNS, and most importantly, our competitors to do some things cooperatively. Gosh, it sounds like a NANOG meeting. On the other hand, the NAP managers, RA, vBNS have to report back to the US government how well they've completed their task, including how the procedures to resolve problems and support end-to-end connectivity and quality of service for network users work. And what does that have to do with the FCC? In the telephony world, the Network Operators Forum serves a similar function, and gets a similar blessing. I'm not suggesting the anyone Internet wants FCC regulations, but it can be instructive to look how other industries handled similar problems. The North American Electric Reliability Council <http://www.nerc.com/> (voluntarily formed after the 1967 northeast blackout) and the Alliance for Telephone Industry Solutions <http://www.atis.org/> had several battles between its members over problems which would sound familar (though not identical) to the typical NANOG meeting. Megawatts or gigabits, the management of dynamic interconnected networks is a challenge for everyone. Instead of reinventing the wheel, we could do a little research and maybe steal some of their ideas. I know the Internet has its own culture, and its own way of doing things. But the net has never been shy about taking good ideas that work, irregardless of their source. On the other hand, if NOF found some ideas don't work, we might avoid the ratholes they ran into. For example, I was a bit surprised to find the industry groups often favored greater reporting of outages than the government wanted. It seems the US government was worried reporting some outage information would give hints to the Soviets where to aim their missles to cause maximum disruption. And even though the FCC permits companies to report outages confidentially, most companies report the information publicly. Which gives me hope some of these same communication companies, different divisions, will participate in an Internet equivalent. One suggestion I found from reading the minutes of the eletric industry meetings, we might change the term from "outage" to "network disturbance." Yes, its an euphemism, like calling a nuclear reactor meltdown an "event." PS, Mr. Metcalfe. Reports for the old reliable telephone system show over the course of a year, a daily average of 30,000 US telephone customers are out of service for five hours. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: 10/8 announced ?
by Sean Doran 11 Jul '96

11 Jul '96

Mutter. We (Sprintlink) do not reject 1918 prefixes from ICM at this time, nor do we (ICM) filter them from announcements from EBONE. I'm sure that this will go away RSN with everyone involved feeling pretty sheepish. Sean. P.S.: >"If we don't have enough IP space, we'll just make >more..." Well, it *was* local use, since we weren't exporting the prefix to our external peers... ;>

1 0