August 1998 - Test - lists.nanog.org

Settlements, etc., etc.
by Derek Elder 26 Aug '98

26 Aug '98

I really wanted to stay out of this one, but something that I remembered from a speech made by an FCC bigwig at ISPCON a couple years ago has pushed me over the edge. His (close enough) statement was "At the FCC, the words "regulation" and "Internet" are not allowed in the same sentence of a document." Their word processors were (supposedly) setup as to not allow it. He stated that the FCC intended to use new IP services (VoIP, etc) to help break up foreign communications monopolies. That is why they were keeping their hands off. So the question that I pose is: Do we actually think that if our greed or inability to find a good peering model, forces us into a "pay for what you use" model, the FCC won't change their minds very quickly and decide that they want their piece of the pie after all? Deciding who is more important - the sender or receiver - is worse than maddening. It's impossible. That's why caller pays in the Telco world and they have alot more infrastructure to track those things than we do. Unfortunatly, I think that this is a train out of control and keeping the regulators out at this point is impossible. Knowing GTE's history (i.e., a company that would never have survived without access charges), who's to say that the BBN movements are not a precisely calculated move to -force- regulators to step in? > Derek Elder > US Web Corporation > Senior Engineer > 212-548-7468 > Pager - 888-232-5028 > delder(a)usweb.com > http://www.usweb.com > A Strategic Partner for the > Information Age. > >

2 1

RE: Urrr... A-root server foul ?
by Dave Van Allen 26 Aug '98

26 Aug '98

! ip subnet-zero ! maybe? Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions > -----Original Message----- > From: Havard.Eidnes(a)runit.sintef.no > [mailto:Havard.Eidnes@runit.sintef.no] > Sent: Wednesday, August 26, 1998 3:49 PM > To: rirving(a)onecall.net > Cc: nanog(a)merit.edu > Subject: Re: Urrr... A-root server foul ? > > > > Is anyone else seeing this? > > Yep, once you point us in that direction. > > > really *cool* udp trick, or is bcast space now DNS capable? > > What am I missing? > > 198.41.0.4 can as far as I can see not be a broadcast address > under any left-contiguous netmask, unless it's the 0'th address > on some subnet and the router sitting on the net has the really- > old-style-and-now-deprecated directed broadcast address > forwarding enabled (not likely). > > A DNS query to 198.41.0.4 does however only elicit a single > response, so I doubt this is much to worry about. (My guess: > they have 4 machines sharing the load via some form of load- > sharing setup.) > > - Håvard >

1 0

Urrr... A-root server foul ?
by Richard Irving 26 Aug '98

26 Aug '98

Is anyone else seeing this ? really *cool* udp trick, or is bcast space now DNS capable ? What am I missing ? Server: ns2.mci.net Address: 204.70.57.242 Non-authoritative answer: Name: A.ROOT-SERVERS.NET Address: 198.41.0.4 And a ping yields ? 64 bytes from 198.41.0.4: icmp_seq=16 ttl=250 time=59 ms 64 bytes from 198.41.0.4: icmp_seq=16 ttl=249 time=76 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=16 ttl=250 time=77 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=17 ttl=250 time=57 ms 64 bytes from 198.41.0.4: icmp_seq=17 ttl=250 time=64 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=17 ttl=249 time=73 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=18 ttl=250 time=71 ms 64 bytes from 198.41.0.4: icmp_seq=19 ttl=250 time=53 ms 64 bytes from 198.41.0.4: icmp_seq=19 ttl=249 time=57 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=19 ttl=249 time=73 ms (DUP!)

4 3

RE: BBN/GTEI
by Goodwin, Dustin 26 Aug '98

26 Aug '98

This ignores the fact that both companies have paying customers. If I am a BBN access customer and I cannot get to any sites, then what good is BBN to me? As an access provider, I built a access infrastructure and I get payed by my customer for providing it to them (include in this cost is the price to connect to content providers). If I am a Exodus customer and I pay for hosting, Exodus is no good to me if it doesn't have any viewers. Exodus built a hosting infrastructure, its customers pay for the right to use that infrastructure(included in this cost is the price to connect to viewers). So both companies need each other. Both companies get payed for providing a service. Where is the problem? Why should BBN get a cut of what Exodus's cutomers pay? BBN is trying to get payed to provide something it needs to from Exodus. If BBN needs it, why would Exodus pay for it? Isn't BBN trying to get payed twice? > -----Original Message----- > From: Michael Dillon [SMTP:michael@memra.com] > Sent: Friday, August 21, 1998 9:13 AM > To: list(a)inet-access.net > Subject: Re: BBN/GTEI > > On Fri, 21 Aug 1998, Brian Wallingford wrote: > > > If you don't peer with or buy > > transit from GTEI, sit back, shut up, and watch and learn (seriously - > > WATCH and LEARN). > > This is seriously good advice. A lot of people have compared this to the > UUNet peering flap but the two incidents couldn't be more different. In > UUNet's case you had John Sidgemore, an economist, attempting to throw his > weight around and push towards a paid peering scenario with a cartel at > the core, all of this based solely on an economics viewpoint. > > But with BBN, there is a network engineering problem at the core of the > issue, that of assymmetric traffic patterns. And BBN realizes that this > sort of assymmetry will become more and more common in the future and that > the industry needs to find some sort of hybrid peering/settlement > mechanism that will work for both parties in an asymmetric arrangement. > They are looking at things like what kind of methodology can be used to > measure the traffic, what constitutes free balanced peering, how to charge > for regional transit on traffic that exceeds the limits of balanced > peering, and similar difficult issues. > > I believe that the reason we are not hearing many details is that there > are NDAs in place about the specifics of the Exodus, AboveNet and CRL > peering contracts. But sooner or later those companies will come to some > sort of agreement and BBN will explain the rationale behind their > thinking. We may not totally agree with that rationale, but I think we can > all see that establishing peering between two specialty providers has to > be handled a bit differently than between two full-service providers. > > And if BBN's ideas can be refined and accepted by the industry, then we > will be in a better position because there will be an established > methodology and pricing structure for an ISP to transition from full > transit to full peering. I know from my experience with Priori that a lot > of peering negotiations happen like an old-boys club cartel and if you > ain't a member of the club, you can't get in. We need to change this so > that there is an open process by which anyone can transition to being a > peer based on an open and accepted methodology and pricing structure. > > -- > Michael Dillon - Internet & ISP Consulting > Memra Communications Inc. - E-mail: michael(a)memra.com > Check the website for my Internet World articles - http://www.memra.com > >

14 22

RE: UUNET Outage in Portland OR
by Chad Skidmore 26 Aug '98

26 Aug '98

It was up within an hour of going down. UUNET was able to get someone on site to deal with the problem. It looks like it took nearly 24hrs for my post to make it onto the NANOG list. Kind of hard to get accurate and timely information out with that kind of delay! ---------------------------------------------- Chad Skidmore Director of Network Engineering Northwest Nexus, Inc. http://www.nwnexus.com 888-NWNEXUS > -----Original Message----- > From: Steve Weaver [mailto:cyberscape@faulkner.com] > Sent: Wednesday, August 26, 1998 1:24 PM > To: Chad Skidmore > Subject: Re: UUNET Outage in Portland OR > > > Chad, > > Anymore on this outage? > > Thanks. > > At 10:27 AM 8/25/98 -0700, you wrote: > >Currently UUNET is experiencing a network outage in Portland > OR. Master > >ticket #0980776. No ETR at this time. > > > >---------------------------------------------- > >Chad Skidmore > >Director of Network Engineering > >Northwest Nexus, Inc. > >http://www.nwnexus.com > >888-NWNEXUS > > > > > > >

1 0

Re: Urrr... A-root server foul ?
by Havard.Eidnes＠runit.sintef.no 26 Aug '98

26 Aug '98

> Is anyone else seeing this? Yep, once you point us in that direction. > really *cool* udp trick, or is bcast space now DNS capable? > What am I missing? 198.41.0.4 can as far as I can see not be a broadcast address under any left-contiguous netmask, unless it's the 0'th address on some subnet and the router sitting on the net has the really- old-style-and-now-deprecated directed broadcast address forwarding enabled (not likely). A DNS query to 198.41.0.4 does however only elicit a single response, so I doubt this is much to worry about. (My guess: they have 4 machines sharing the load via some form of load- sharing setup.) - Håvard

1 0

Re: Generation of traffic in "settled" peering arrangement
by Sean M. Doran 26 Aug '98

26 Aug '98

Vadim replying to me wrote: | > Actually the distribution problem is pretty simple. | > | > In your forwarding table add a per-prefix cost. | > | > The cost is expressed in terms of tokens. | > | > The tokens are deducted from a token bucket. | > | > The number of tokens in the bucket (depth and refresh-rate) is | > arrived at by some engineering or sales process. | > | > This polices MEDs nicely. | | Hm. Aggregation breaks that scheme nicely. Absense of | aggregation breaks routing nicely. Remember Yakov's route push and route pull model. In the system above, when you have multiple connections to someone sending you only very short (aggregate) prefixes, you have an incentive to do a route pull in order to optimize your routing. That is, you can acquire information about the other network to help you choose the cheapest entry point. Moreover, the route pull does not have to be very dynamic in order to increase (as opposed to maximize) the number of packets you are able to send into the network. Sean. P.S.: There is also a direct trade-off -- choosing the most expensive entry point merely minimizes the number of packets one will be able to inject into the other network for any given token-bucket- refresh-rate. Rather than choose cheaper entry points, one could simply choose to buy a faster refresh-rate.

2 1

BBN/GTE Enough already!?
by Tim Wolfe 26 Aug '98

26 Aug '98

Could people please take it upon themselves to move this discussion off list? The sheer number of emails on this subject is kind of ridiculous considering for most of us this is not currently an operational issue.. While I'm as interested in the political implications of this as the next guy, I just don't have the time to read it all anymore. I know com-priv has been suggested a number of times as a more appropriate venue for this discussion and I would agree with those statements. Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

2 1

Price Per Packet
by howland＠Priss.com 26 Aug '98

26 Aug '98

Lets see. Network "A" and network "B". A charges B for every packet sent or received. B charges A for every packet sent or received. Net result, Zero. Everything else is merely "My customer is more important than your customer" ego-stroking. Can we please move on to something less motivated by self-centered greed? Curt-

1 0

Re: Sprint/HiNet
by Jay Stewart 26 Aug '98

26 Aug '98

Maybe the ISP is using a router that doesn't respond to ICMP, like the Livingston IRX, or others?? Jay Stewart Vice President OlyWa.Net - "Olympia's Premier Internet Service Provider" -----Original Message----- From: william(a)pacific.net.ph <william(a)pacific.net.ph> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Wednesday, August 26, 1998 11:58 AM Subject: Sprint/HiNet Hi all! Whenever we do a traceroute from our Sprint connection to a host in the HiNet network, we get timed out in the Sprint/HiNet link, as follows: Tracing route to w3.hinet.net [168.95.1.82] over a maximum of 30 hops: 1 138 ms 116 ms 113 ms pi-ph-ts01.pacific.net.ph [210.23.234.128] 2 142 ms 111 ms 116 ms pi-ph-gw01.pacific.net.ph [210.23.234.1] 3 332 ms 330 ms 340 ms 204.59.178.25 4 375 ms 324 ms 328 ms 204.59.120.198 5 323 ms 322 ms 339 ms 144.232.1.153 6 380 ms 366 ms 365 ms 144.232.8.70 7 347 ms 373 ms 374 ms 144.232.4.142 8 * * * Request timed out. 9 546 ms 529 ms 523 ms 168.95.253.126 10 540 ms 532 ms 540 ms 168.95.253.189 11 547 ms 556 ms 547 ms w3.hinet.net [168.95.1.82] Trace complete. Line 8 is always like this and a customer of ours is complaining about it. Is this a time out or congestion or something else? William

1 0