- Test - lists.nanog.org

Re: NANOG
by Wolfgang Henke 03 Apr '96

03 Apr '96

bob_metcalfe(a)infoworld.com (Bob Metcalfe) wrote: Perhaps I am confusing terms here. How can it be a fact that "store-and-forward delays are a mere fraction of wire propagation delays?" I don't think so. Check me on this: Packets travel over wires at large fractions of the speed of light, but then sadly at each hop they must be received, checked, routed, and then queued for forwarding. Do I have that right? Forget checking, routing, and queueing (ha!), and you get, I think, that store and forward delay is roughly proportional to the number of hops times packet length divided by circuit speed (N*P/C). For 10 hops of a thousand bit packet at Ethernet speed, that would be 1 ms, or a couple hundred miles of prop delay. Check me on this, one of us might be off by several orders of magnitude. Hmm... Using a real in use backbone of one of the mayor service providers, I find that a DS3 between silicon valley to Chicago has a 44 msec latency going through 4 hops. That's about the speed of light in fiber for the 5000 mile roundtrip ICMP ping packets. Using ATM will reduce the router latency. I estimate that with TCP/IP over ATM over SONET OC-3c the latency will be reduced from 44 msec to 40 msec, only a rather small improvement. The bandwidth used on the fiber wont matter much. With OC-12c I would still expect 40 msec or so since the speed of light in fiber is the limiting factor. Wolfgang

3 2

RE: NANOG
by bob_metcalfe＠infoworld.com 03 Apr '96

03 Apr '96

Dear Mr. Antonov, Thanks for taking time to enter this little spat about Internet collapses, the growing importance of NANOG, and my cluelessness. You wrote: >I was in a backbone engineer's skin for quite a few years, and "hops" >per se never were a problem. In fact, store-and-forward delays are >a mere fraction of wire propagation delays -- do a traceroute coast-to-coast, >look at delays and calculate how it relates to distance divided by speed of >light. Indeed, you're the first person concerned with the growth of diameter >(which is, BTW, logarithmic to size of the network). Perhaps I am confusing terms here. How can it be a fact that "store-and-forward delays are a mere fraction of wire propagation delays?" I don't think so. Check me on this: Packets travel over wires at large fractions of the speed of light, but then sadly at each hop they must be received, checked, routed, and then queued for forwarding. Do I have that right? Forget checking, routing, and queueing (ha!), and you get, I think, that store and forward delay is roughly proportional to the number of hops times packet length divided by circuit speed (N*P/C). For 10 hops of a thousand bit packet at Ethernet speed, that would be 1 ms, or a couple hundred miles of prop delay. Check me on this, one of us might be off by several orders of magnitude. But at 30 hops of thousand byte packets at T1 speeds, that's, what? 4,000 miles of prop delay. A mere fraction? OK, maybe soon the entire Internet backbone(s) will be ATM at 622Mbps, which would certainly knock some of the wind out of N, P, and C. Soon? But of course, getting back to 1996, N*P/C doesn't count checking, routing, and queueing -- queueing gets to be a major multiple with loading. Oh, I forgot retransmission delays too, at each hop. And I forgot the increasing complications of route propagation as hops increase... If I am, as you say, the first person to be concerned with the growth of Internet diameter, which I doubt, then I deserve a medal. Or is my arithmetic wrong? Ease my cluelessness. /Bob Metcalfe, InfoWorld At 6:44 PM 4/2/96, Vadim Antonov wrote: >Received: by ccmail from lserver.infoworld.com >>From avg(a)postman.ncube.com >X-Envelope-From: avg(a)postman.ncube.com >Received: from postman.ncube.com by lserver.infoworld.com with smtp > (Smail3.1.29.1 #12) id m0u4IvH-000wq4C; Tue, 2 Apr 96 19:07 PST >Received: from butler.ncube.com by postman.ncube.com (4.1/SMI-4.1) > id AA19923; Tue, 2 Apr 96 18:42:20 PST >Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) > id AA02534; Tue, 2 Apr 1996 18:40:46 +0800 >Date: Tue, 2 Apr 1996 18:40:46 +0800 >From: avg(a)postman.ncube.com (Vadim Antonov) >Message-Id: <9604030240.AA02534(a)butler.ncube.com> >To: bob_metcalfe(a)infoworld.com, jerry(a)fc.net >Subject: RE: NANOG >Cc: letters(a)infoworld.com, nanog(a)merit.edu >Content-Length: 2913 > >Bob Metcalfe wrote: > >>Note, I have never predicted "the death of the Internet," only catastrophic >>collapse(s) during 1996, which is "a good calibration" of the rest of your >>objections (below). > >One does not need to be Nostradamus to predict that s*t happens. >It happened in the past, many times, too. Like when me and Sean >installed a just-baked SSE into a DC box and it looked fine but >screwed nearly all connectivity to Europe for few hours when we were >trying to figure out what was going on. Or when FIX-E<->ICM-DC >Bell Atlantic's DS-3 was flapping like mad when moon was >in the wrong phase and BA did nothing to fix it for months. Or when >some sequence of 1s and 0s was triggering some bulls*t alarms in >Sprint fiber network so causing shutdowns on the entire OC-24 trunk. >Or when a bogus static route in a Sprint's box was causing ANS's >version of gated to go banana and drop BGP sessions. Or many many >more occasions when "Bysantine-mode failure" becomes ugly reality in >the middle of the night so causing more than few people to be dragged >out of beds. > >As long as Internet technology is freaking bleeding edge and operators >are in the "code of the day" club catastrophes are bound to happen. > >>Jerry, Jerry, Jerry, the problem is not that the Internet's chief 100 >>engineers, whoever they are, fail to report their problems to me, it's that >>they (you?) fail to report them to anybody, including to each other, which >>is half our problem. > >That is simply not true. The backbone engineering society is tightly >knit and quite often backbone engineers are simply personal friends. >I certainly never had a problem with people refusing to fix problems >within their domains (well, PSI's TWD is not an operational problem). >The organization-level corrdination is often broken at operators level, >but that is merely a function of severe shortage of qualified personnel >and inadequate compensation for the high-stress job. > >>Settlements, "wrong on the face?" Or are you just too busy busy busy >>defensive to argue? > >Before you talk of settlements answer the simple question -- >a packet travelled from provider A to provider B. Who should pay >to whom? Then, please, stop perpetuating nonsense. > >>So, you say, increasing Internet diameters (hops) are only of concern to >>whiners like me? There are no whiners LIKE me. I am THE whiner. And hops >>ARE a first class problem, Jerry, or are you clueless about how >>store-and-forward packet switching actually really works? > >I was in a backbone engineer's skin for quite a few years, and "hops" >per se never were a problem. In fact, store-and-forward delays are >a mere fraction of wire propagation delays -- do a traceroute coast-to-coast, >look at delays and calculate how it relates to distance divided by speed of >light. >Indeed, you're the first person concerned with the growth of diameter >(which is, BTW, logarithmic to size of the network). > >--vadim ______________________________________________ ______________________________________________ Dr. Robert M. ("Bob") Metcalfe Executive Correspondent, InfoWorld and VP Technology, International Data Group Internet Messages: bob_metcalfe(a)infoworld.com Voice Messages: 617-534-1215 Conference Chairman for ACM97: The Next 50 Years of Computing San Jose Convention Center March 1-5, 1997 ______________________________________________ ______________________________________________

2 1

Re: vocalizing majors, etc, etc.....
by hcb＠clark.net 03 Apr '96

03 Apr '96

>"No one expects the Spanish Inquisition!" > >:-) > >- paul > Come now, Paul. The Spannish Tree Inquisition is for large-scale bridged networks, not the routed Internet.

1 0

Re: New Internet Routing Statistics
by Sean Doran 03 Apr '96

03 Apr '96

| So sprint will coperate at least to the extent that MCI, ANS, and UUNET | are already doing so? If Craig had previously pointed out that he would like to have gotten routes from us that would not be propagated unless specifically requested by us, then I don't think it would have been too difficult to have done the two line adjustment to our already-existing peerings with the two RSes at MAE-EAST in order for us to have shown up on the hallowed list in his message today. Of course, that would have also deprived you of a front-page Cook Report scandal, and several messages here on the NANOG list. So, think of this as job creation at work, maybe. | I'd think that is good news. Do you have any kind of time line, Sean? | June 1? July 1? Well, I went digging, and couldn't find any relevant email on the first pass. Perhaps such a message will find its way to the appropriate people (maybe for the second time, if we lost things on this end), so we know what routing information is wanted and where and when, and what exactly it will be used for. I see no difficulty with announcing routes to the RA specifically for gathering the sorts of statistics they have been thinking about. Indeed, I believe that I have made this clear in public places a number of times in the past. We now return you to the regularly scheduled making of mountains out of mole-hills. Sean. P.S.: SL-MAE-E uptime is 1 week, 4 days, 12 hours, 37 minutes System restarted by power-on at 10:28:06 EST Fri Mar 22 1996 BGP neighbor is 192.41.177.166, remote AS 2885, external link NEXT_HOP is always this router BGP version 4, remote router ID 192.41.177.166 BGP state = Established, table version = 2186252, up for 1w0d Last read 0:00:57, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 16570 messages, 0 notifications, 0 in queue Sent 16605 messages, 0 notifications, 0 in queue Incoming update network filter list is 112 Outgoing update network filter list is 95 Outgoing update AS path filter list is 35 Route map for incoming advertisements is RA Connections established 4; dropped 3 [moreover, we set the peering up more than a year ago]

2 1

Re: Sprint's agenda
by Sean Doran 03 Apr '96

03 Apr '96

There is nothing new here; it is Common Knowledge that Sprint is the source of all evil on the Internet, and is out to crush small providers, and make sure that everyone in the world burns his or her toast, and so on and so forth. Everyone has been welcome to draw their own conclusions from day one. Sean. - -- | From nanog-owner(a)merit.edu Wed Apr 3 15:52:13 1996 | From: jon(a)branch.com (Jon Zeeff) | Subject: Sprint's agenda | To: pferguso(a)cisco.com (Paul Ferguson) | Cc: michael(a)memra.com, nanog(a)merit.edu | MIME-Version: 1.0 | Content-Transfer-Encoding: 7bit | Sender: owner-nanog(a)merit.edu | | | > And the global routing table grows. | | We asked Sprint for an exception to their routing policy in a case that | would clearly reduce routing table size. They said no. Everyone is | free to draw their own conclusions regarding Sprint's policies and the | real motivations behind them. | |

1 0

RE: NANOG/IEPG/ISOC's current role
by Jim Fleming 03 Apr '96

03 Apr '96

On Monday, April 01, 1996 4:10 PM, Michael Dillon[SMTP:michael@memra.com] wrote: @On Mon, 1 Apr 1996, Sean Donelan wrote: @ @> Is this just a case of bad reporting by Joanie Wexler at NetworkWorld? A @> bad case of passing the buck by Alecia Cooper at Sprint? Or something else? @ @It's most definitely something else. Most people are trained from birth @that organizations with acronyms rule the world, thus NANOG and IEPG @and ISOC must be the rulers of the Internet world. @ Yes, as more people from various walks of life get involved in the Internet, there is going to be confusion because these "new" people are going to assume that there is something behind these fancy acronyms... when they find out that the Internet is like a large "movie set" they may get very upset...or at least disoriented...they will find that the net is not an Information Superhighway but rather a parking lot with carnival rides... ...this will probably send many people BACK to their families, churches, schools, governments, corner barber shops and neighbors to try to find something "real" in their life...in this respect, the Internet may cause people in local areas to become "better connected" because much of the net is very socially disconnected... ...virtual is fun but when the rubber hits the road...people buy ($$$) real... @Since most NANOG/IEPG/ISOC people are clueless when it comes to things @like public relations, press releases, spin control, etc... is it any @wonder that the press marches merrily off in their own direction. @ I am not sure they are clueless, they may have just chosen to live in a different world where the traditional press has little meaning....keep in mind that Dolphins do not get involved much in the world of Cats and Dogs... @There is actually opportunity here for groups like NANOG to have some @influence and communicate with the public in a positive fashion. I @suggest that a good first step would be to release a communique to the @press after every NANOG meeting and a good second step would be to urge @ISOC to spend more money on general educational issues to make people in @general more aware of operational and architectural issues. @ @ @Michael Dillon Voice: +1-604-546-8022 Maybe people that live largely in the Internet (and other places) are going to discover what the other 99% of the people on planet earth already know.... In order to get people working in a common direction you have to have some common purpose, some common goals and a reason and benefit for an individual to be associatted with an entity. Having a short, catchy acronym is not enough. Most humans do not join clubs or help promote a cause simply because it exists. One or more of the basic human motivators need to be in place. (education, money, power, entertainment, self-fullfillment, social status, peer acceptance, pleasure, etc.) The Internet is currently going through a transition...many of the traditional groups that have been formed in the "real world" (whatever that is) are moving some or part of their member communication to the Internet. Most of it shows up in the World Wide Web...little by little, traditional groups will discover some of the other "services" available on the net. When this occurs these groups will likely overshadow the tiny groups that helped to build the net. I suggest that "net people" give up on the idea of building more and more "movie sets" and instead, join with the real people and help facilitate their increased involvement with the net. This involvement is inevitable and as they say..."If you can't beat them... join them"...By joining with existing groups, netizens can have a significant impact on how those groups merge into the increasing traffic on the Information Parking Lot... -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

Re: vocalizing majors, etc, etc.....
by bill＠sf.net 03 Apr '96

03 Apr '96

>"Do you now, or have you ever attended meetings of the Global > Routing Conspiracy?" > >"Huh?? I went to a NANOG meeting a few times to see what went on there." > >"So you ADMIT that you have attended SEVERAL meetings of the > Global Routing Conspiracy?" [deletia] Mike, Is this based on personal experience? Or is this merely a nightmare you anticipate? ;) Bill

1 0

Re: NANOG/IEPG/ISOC's current role
by Hank Nussbacher 03 Apr '96

03 Apr '96

I use a simple rule that seems to work somewhat in regards to renumbering. I control the Israeli /16s blocks - i.e. 192.114-118.0.0/16. An organization that uses a /22 or more (and use means more than 50% of the IP address space is being used), is allowed to move around with it from ISP to ISP (i.e. portable). If you have 500 machines - it is painful to renumber (not impossible). If you have 30 machines and a /24, then renumber - and I have reclaimed dozens of /24s in this fashion. Hank

1 0

Re: Sprint's agenda
by avg＠postman.ncube.com 03 Apr '96

03 Apr '96

Jon Zeeff wrote: >> And the global routing table grows. >We asked Sprint for an exception to their routing policy in a case that >would clearly reduce routing table size. They said no. Everyone is >free to draw their own conclusions regarding Sprint's policies and the >real motivations behind them. Cisco's configurations aren't rubber. You can only stretch them so far. Every exception is more stuff in configuration on a dozen of routers. This also increases CPU load. If you think Sprint's goal is to reduce table size you're wrong. The goal is to avoid routers going belly up from overload. So the approach is to have a blanket policy which is not too expensive to compute but does contain growth _on average_. --vadim PS. Here's line counts for you to appreciate better why Sprint engineering does not like exceptions: 1291 icm-dc-1-confg 191 icm-dc-2-confg 542 icm-dc-2b-confg 1155 icm-dc-3-confg 792 icm-fix-e-confg 842 icm-fix-w-confg 314 icm-lac-1-confg 1194 icm-mae-e-confg 164 icm-moscow-1-confg 398 icm-pen-1-confg 447 icm-pen-2-confg 418 icm-stockholm-2-confg 190 icm-uk-1-confg 399 sl-ana-1-confg 386 sl-ana-2-confg 737 sl-ana-3-confg 559 sl-ana-4-confg 435 sl-ana-5-confg 451 sl-ana-6-confg 242 sl-ana-7-confg 356 sl-atl-1-confg 361 sl-atl-2-confg 496 sl-atl-3-confg 420 sl-atl-4-confg 353 sl-atl-5-confg 401 sl-che-1-confg 403 sl-che-2-confg 417 sl-che-3-confg 301 sl-chi-1-confg 521 sl-chi-10-confg 587 sl-chi-11-confg 187 sl-chi-12-confg 513 sl-chi-13-confg 480 sl-chi-14-confg 393 sl-chi-15-confg 354 sl-chi-2-confg 440 sl-chi-3-confg 713 sl-chi-4-confg 608 sl-chi-5-confg 453 sl-chi-6-confg 610 sl-chi-7-confg 453 sl-chi-8-confg 507 sl-chi-9-confg 572 sl-chi-nap-confg 496 sl-dc-1-confg 734 sl-dc-10-confg 677 sl-dc-11-confg 642 sl-dc-12-confg 575 sl-dc-13-confg 543 sl-dc-14-confg 459 sl-dc-15-confg 503 sl-dc-16-confg 791 sl-dc-17-confg 382 sl-dc-18-confg 391 sl-dc-2-confg 495 sl-dc-3-confg 731 sl-dc-4-confg 551 sl-dc-5-confg 847 sl-dc-6-confg 406 sl-dc-7-confg 662 sl-dc-8-confg 677 sl-dc-9-confg 181 sl-dc-s-1-confg 495 sl-fw-1-confg 502 sl-fw-10-confg 532 sl-fw-11-confg 518 sl-fw-12-confg 512 sl-fw-13-confg 472 sl-fw-14-confg 359 sl-fw-15-confg 484 sl-fw-2-confg 831 sl-fw-3-confg 480 sl-fw-4-confg 479 sl-fw-5-confg 413 sl-fw-6-confg 460 sl-fw-7-confg 507 sl-fw-8-confg 449 sl-fw-9-confg 391 sl-hrn-1-confg 369 sl-kc-1-confg 368 sl-kc-2-confg 1076 sl-mae-e-confg 739 sl-mae-w-confg 673 sl-pen-1-confg 447 sl-pen-10-confg 390 sl-pen-12-confg 512 sl-pen-13-confg 316 sl-pen-14-confg 352 sl-pen-15-confg 948 sl-pen-2-confg 613 sl-pen-3-confg 451 sl-pen-4-confg 524 sl-pen-5-confg 606 sl-pen-6-confg 546 sl-pen-7-confg 542 sl-pen-8-confg 505 sl-pen-9-confg 389 sl-sea-1-confg 392 sl-sea-2-confg 442 sl-sea-3-confg 438 sl-sea-4-confg 375 sl-sea-5-confg 459 sl-stk-1-confg 600 sl-stk-10-confg 590 sl-stk-11-confg 492 sl-stk-12-confg 504 sl-stk-13-confg 358 sl-stk-14-confg 380 sl-stk-15-confg 544 sl-stk-2-confg 531 sl-stk-3-confg 904 sl-stk-4-confg 618 sl-stk-5-confg 638 sl-stk-6-confg 555 sl-stk-7-confg 592 sl-stk-8-confg 541 sl-stk-9-confg 461 sl-stk-nap-confg 61453 total

1 0

RE: NANOG
by avg＠postman.ncube.com 03 Apr '96

03 Apr '96

Bob Metcalfe wrote: >Perhaps I am confusing terms here. How can it be a fact that >"store-and-forward delays are a mere fraction of wire propagation delays?" >I don't think so. Check me on this: >Packets travel over wires at large fractions of the speed of light, but >then sadly at each hop they must be received, checked, routed, and then >queued for forwarding. Do I have that right? Not "checked". Nobody computes checksums in gateways for transit packets. Updating hopcount doesn't require recalculation of IP checksum, it can be done incrementally (there was an RFC to that effect, don't remember which). >Forget checking, routing, and queueing (ha!), and you get, I think, that >store and forward delay is roughly proportional to the number of hops times >packet length divided by circuit speed (N*P/C). Wrong. This is oversimplification, as slow tail-links consume bulk of time. This is very comparable to going 90% of the way at 100mph and 10% at 10mph -- what is the average speed? Right, that's 52.6 mph. Note that 10% of the way slows down everything by a half. >But at 30 hops of thousand byte packets at T1 speeds, that's, what? 4,000 >miles of prop delay. A mere fraction? You won't find 30 hops at T-1 in the real life no matter how hard you try. It's more like Ethernet-T1-FDDI-T3-FDDI-T3-T3-FDDI-T3-FDDI-T1-Ethernet- T0-Ethernet. And, BTW, the average size of packet on Internet is 200 bytes. Store-and-forward of 200-byte packet is 60 microseconds with T-3 wire which is about 5 miles at light speed. Moreover, large packets occur in bulk transfers, where sliding windows are efficient -- to the effect that you see the delay only once, when you do initial TCP handshake. >But of course, getting back to 1996, N*P/C doesn't count checking, routing, >and queueing -- queueing gets to be a major multiple with loading. Queueing Theory 101 is recommended. If incoming traffic in G/D/1 system is less than capacity the average queue size is less than 1. If load is more than capacity the average queue size is infinity. I.e. the delay in network in case of congestion depends on size of buffers along the path, and not number of hops, period. The "best" size of buffers is choosen to accomodate transient congestions, i.e. determined from bandwidth*delay product ("delay" here is RTT). I.e. in properly tuned network the congestion delay is about 2 times "ideal" RTT plus something to accomodate topological irregularities. RED (by VJ and co.) allows to reduce size of congestion buffers by about 1/2 because it actively anticipates congestions instead of acting when they already happened as tail-drop does. And, BTW, with IP you can skip the "store" part, too; you only need to look at IP header to make a routing decision. The rest you can simply channel thru. >Oh, I forgot retransmission delays too, at each hop. What's that? IP does not do any retransmissions between gateways. >And I forgot the increasing >complications of route propagation as hops increase... He-he. That is far from being as simple as you think. Topology means a lot more than the diameter for complexity of routing computations. >If I am, as you say, the first person to be concerned with the growth of >Internet diameter, which I doubt, then I deserve a medal. Or is my >arithmetic wrong? Ease my cluelessness. You seem to offer opinions with little or no checking of background facts. I bet you're a victim of Flame Delay crowd propaganda. I certainly heard that line of reasoning from them, got a good laugh, too. As for cluelessness -- i already noted that diameter grows as a logarithm of network size, while bandwidth grows at least as linear to the size. That means that the fraction of "store-and-forward" penalty in the end-to-end delays is diminishing as network grows. So not only you're worrying about insignificant thing, you appear concerned with something which actually improves with scale! --vadim

1 0