- Test - lists.nanog.org

Re: critique of NANOG meeting
by avg＠postman.ncube.com 19 Jun '96

19 Jun '96

Jeff Young wrote: >metcalfe understands the issues only too well. only the truly >blessed can blindly exploit half-truths. he is not blessed and >he is not blind. >i have no doubt that his campaign will succeed. he is bright, has >built companies, used to be a technically saavy engineer. the trick >will be to bide our time, he will go away in the end. hopefully his >winnings will be modest this time. You made him to look cunning and evil. I'd like to make him to look ridiculous. That's harmless at least and there's a chance that this will make him to go away. Actually i don't understand what his motivation is. It appears that it is not material; and any decent person wouldn't just go and use somebody else's problems as a ladder to do social climbing. --vadim

3 2

Re: critique of NANOG meeting
by Paul Ferguson 19 Jun '96

19 Jun '96

At 12:33 AM 6/20/96 +0200, Per Gregers Bilse wrote: > >Bob is actually quite funny at times, I liked the thing about wearing >a tie. Can we get somebody to send a reminder on the IETF announcement >list, for people to bring ties and testboot their laptops before >turning up in Montreal? > Oh, please do. ,-) - paul

1 0

Re: critique of NANOG meeting
by Avi Freedman 19 Jun '96

19 Jun '96

> Load balancing is a funny stuff. Its utility is very limited > by the fact that you've got to keep packets in sequence to > avoid triggering TCP fast retransmits. > > I.e. with ciscos you can only do load-balancing on paths > (i.e. load one circuit with traffic to ISP A and another to ISP B > etc) or on destination networks (that has a potential of causing > very skewed load distribution). I admit I'm not familiar with the impact of 'ip route-caching' tens of thousands of equal-cost paths at dual-HSSI speed. I was told by some at Cisco that it wouldn't be a problem. > Before i left Sprint i produced a plan for them to increase > capacity at least four-fold using combination of load balancing > and hot-potato intra-backbone routing. Going to OC-3s is > a lot simplier, though :) True, it's simpler - but one does what one needs to do to stay alive. Or one should, at least :) > --vadim Avi

1 0

Re: Netcom Issues
by Sean Donelan 19 Jun '96

19 Jun '96

> I'm seeing alot of problems with Netcom, and I can't seem to get > any info from them, the net, or the normal grapevine. > > Anyone have any info to share? Would this be a good time to remind folks that Stan Barber set up a list to discuss methods of inter-provider service outage notification at the last NANOG. Subscribe by sending a message to outage-discuss-request(a)academ.com, with "subscribe" in the body of the message. Hopefully folks will begin to realize it is in their own self-interest to let folks know when things aren't working. Its hard to work on fixing the problem when all your phone lines are swamped with customers (and other providers) telling you things aren't working. Not even AT&T has enough telephone operators to handle all the calls when their network goes down. So far I've come up with two models. Telephone model: inband notification, such as a busy signal. The ideal would be for a way to wedge an explaination into the ICMP unreachable message. This is similar to the phone company putting a message "You call can't go through because of an earthquake in the area" instead of just a busy signal. Airline model: out-of-band notification, such as the arrivals/departures displays at airports. Query some (hopefully distributed) database for current network information for each network. This is similar to the airport flight displays that say on-time, boarding, delayed, crashed for each flight. Remember, if you don't provide the information, your competitors will make something up. I've already seen one posting that (falsely) claimed NETCOM went out of business. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: tilting at windmills discussion 2
by avg＠postman.ncube.com 19 Jun '96

19 Jun '96

>IP packet size distribution (970780293 total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 > .000 .497 .094 .013 .009 .006 .007 .010 .010 .014 .004 .005 .002 .002 .002 > ^^^^ > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .004 .002 .189 .000 .069 .053 .000 .000 .000 .000 .000 > >Collected at a private interconnect between CICNet, OARnet and OSU. over a >period of a week or so. This is not surprising if you think of it. Short packets are pure ACKs, telnet keystrokes and SYNs. What is worrying is the peak at 576. It means TCP unable to grasp that path MTU is really 1.5K. --vadim

2 1

Re: critique of NANOG meeting
by Avi Freedman 19 Jun '96

19 Jun '96

> Not that simple -- some folks at MAE-E already have > their DS-3s saturated. > > --vadim > Also, I explained the Cisco route retraction bug/feature and > that most of the packet loss that's not caused by total port > outages is due to limited provisioning of bandwidth into the > exchanges, not due to exchange fabrics losing packets or > routers dropping packets due to anything but wan link saturation. > In general, that is :) > > Avi So more routers & more wan links are required by those providers, no? I didn't say it's easy to do, but it's not impossible either. Load-balance external peering, and either load-balance wan links or pull the wan links to different locations. MCI said they plan on increasing dramatically the # of pipes they have to the public exchange points... Avi

1 0

Re:critique of NANOG meeting
by avg＠postman.ncube.com 19 Jun '96

19 Jun '96

>From: Michael Dillon <michael(a)memra.com> >I don't know if you folks are following Metcalfe's columns... The guy is seriously out of touch with reality. He seems to be completely unable to comprehend the fact that packet loss is not a malfunction but rather the nature's way to say "you need more bandwidth". And the fact that it was exactly suits who got Internet to that point; engineers keet screaming about inadequate facilities for as long as i could remember. And if he thinks backbone engineers have time to prepare slides (or have secretaries to do that for them) i'd like to move to the world he's living in. --vadim

5 4

Re: Netcom Issues
by Bill Woodcock 19 Jun '96

19 Jun '96

We've got a multi-homed customer that also uses them... I tracerouted out from the CPE into Netcom, and it only got one hop in, to their San Francisco routers... Died before getting down to their San Jose stuff. I don't know much about their internal architecture, so I can't speculate what that means precisely. We called their tech support number, and got a message that they were having a "general network fault" or some such. :-) We first noticed it just after 3:00pm yesterday, Tuesday. -Bill Woodcock

1 0

Re: tilting at windmills discussion 2
by scharf＠vix.com 19 Jun '96

19 Jun '96

Justin W. Newton <justin(a)erols.com> writes: > Do you also happen to have a breakdown of what ports this raffic was going > to/from? The reason I ask iss that this seems to lead to a conclusion that > a lot of the data was for "interactive" services such as telnet and the like > as opposed to batch transfer type of connections such as ftp, and sendmail. go look at http://www.nlanr.net/NA and the parent directory of the URL in the original mail. k claffey and folks have done a great job of collecting loads of stats and analyzing them 17 different ways. Anyone interested in doing traffic statistics work should start there. Jerry

1 0

Re: tilting at windmills discussion 2
by salo＠msc.edu 19 Jun '96

19 Jun '96

> In a similar vein, something to think about: > > IP packet size distribution (970780293 total packets): > 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 > .000 .497 .094 .013 .009 .006 .007 .010 .010 .014 .004 .005 .002 .002 .002 > ^^^^ > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > .004 .002 .189 .000 .069 .053 .000 .000 .000 .000 .000 > > Collected at a private interconnect between CICNet, OARnet and OSU. over a > period of a week or so. It would be really interesting if you could expand the range of 32 to 64 byte packets to display in one byte increments. Then we could try to guess: o How many packets are nothing but TCP and IP headers? o How many packets appear to be TCP/IP headers with one byte of data? o How many of these packets, with some sort of header compression scheme, could fit in one ATM cell? o Etc., etc. -tjs

2 1