- Test - lists.nanog.org

RE: CIDR,Sprint and the Big Guys.
by salo＠msc.edu 06 Apr '96

06 Apr '96

> Date: Fri, 05 Apr 1996 17:12:24 -0800 > To: salo(a)msc.edu (Tim Salo), nanog(a)merit.edu > From: "Kent W. England" <kwe(a)6SigmaNets.com> > Subject: RE: CIDR,Sprint and the Big Guys. > > At 08:25 AM 4/5/96 -0600, Tim Salo wrote: > >Perhaps, the [anticipated] consolidation of ISPs will be a significant > >event in the efforts to control routing table size. > > > Do we need address leasing to hasten that process or should we let the > market decide? In any event, anyone buying up a bunch of ISPs will have a > difficult time cleaning up the aggregation of addresses they inherit. Obviously, cleaning up the current swamp is difficult. On the other hand, should consolidation occur, presumably a smaller number of larger ISPs would use a smaller number of larger address blocks, (plus or minus issues of the magnitude of dual-homing and changing upstream providers). -tjs

1 0

Re: Address "portability"
by Paul Ferguson 06 Apr '96

06 Apr '96

At 06:39 PM 4/5/96 -0500, Justin W. Newton wrote: >At 12:32 PM 4/5/96 -0800, Matthew Kaufman wrote: > >>The California PUC has approved local phone competition within California, >>with the requirement the phone number portability (between carriers) be >>fully implemented as soon as possible. Making your phone number stay the >>same no matter whether you're a PacBell or MFS or TCI customer is exactly >>the same problem as making IP addresses portable... just wait until ISPs >>are regulated, and they get the same mandate. > >Uhm, Cisco, you hear that? > > Um, and pray tell, what exactly is cisco supposed to do about this? I'll write my congresscritter if you write yours. :-) - paul

2 1

Re: 192/8 survey (was Re: NANOG/IEPG/ISOC's current role)
by Paul Ferguson 06 Apr '96

06 Apr '96

At 05:09 PM 4/5/96 PST, Suzanne Woolf wrote: >In addition, we did some preliminary analysis on routing table entries >for /24s in 192/8, which we presented in the IEPG meeting on March 2, >available as http://www.isi.edu/div7/pier/whose_routes. But the >indications so far are that the required contact information is >scattered and incomplete. Suzanne, This URL appears to be non-existent. :-) - paul

1 0

RE: the Internet Backbone
by Jim Fleming 06 Apr '96

06 Apr '96

On Friday, April 05, 1996 1:55 PM, Paul Ferguson[SMTP:pferguso@cisco.com] wrote: @Better yet, call it the 'default-free core', which is ironically what it @is already called. :-) @ @- paul @ Actually some of the large carriers do have a hidden default route...to the bit bucket...:-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

Re: ATM overhead
by Paul Ferguson 06 Apr '96

06 Apr '96

At 05:12 PM 4/5/96 -0800, Kent W. England wrote: > >I have been doing some more arithmetic on the "ATM cell tax" to see if I can >find out how folks get from 10% (which is the 5/53 overhead) to 35% >overhead. I would really really like to see some backup for those sort of >numbers -- I can't make the arithmetic work out to anything near 35% for >what I think are useful assumptions. Of course, if you want to posit 100% >of IP traffic with 49 bytes, but that doesn't seem realistic and you >shouldn't forget that 40 of those are TCP/IP overhead. :-) > >What traffic mix do you use to calculate ATM overhead and what results do >you get? > Trying to avoid reinventing the arithmetic wheel here, I've taken the liberty of cutting-and-pasting a couple of snippets from earlier discussions on this topic. [snip] Date: Tue, 19 Mar 1996 19:51:33 -0800 From: Jim Forster <forster(a)cisco.com> Sender: owner-nanog(a)merit.edu He's talking about the overhead due to carrying variable length IP packets in fixed length ATM cells. Consequently the last cell of an AAL5 frame will contain 0 - 39(?) bytes of padding, which is wasted bandwidth. Assuming random length distributions (which they're not), the average waste is about 20 bytes per packet. My rough estimate, based on an average packet size of 200 bytes (used to be correct, not sure anymore), is that the waste due to cell padding is about 10%. Due to the highly skewed packet size distribution the actual overhead might vary substantially. Note that this 10% is on top of the ~10% overhead due to the 5 byte ATM cell headers (5/53 ~= 10%), and various other overheads (some of which are also present in frame over Sonet schemes). There's beginning to be some expectation that there will be a transmission capacity crunch in the carrier's Sonet nets, and this ~25% ATM cell tax may be looked at carefully as packet over Sonet solutions emerge. [snip] From: Wolfgang Henke <wolfgang(a)whnet.com> Date: Tue, 19 Mar 1996 20:34:05 -0800 (PST) Sender: owner-nanog(a)merit.edu Great. Let's estimate the ATM bandwidth available on an OC-3. With STS-3c SONET at 155.520 Mbps it gets reduced to 149.760 Mbps due to section, line and path SONET overhead. Next we reduce 10% due to 20 bytes lost on average 200 byte long packets due to incomplete ATM cell fills resulting in 134.784 Mbps. Then we need to subtract 9.43% due to ATM headers of 5 bytes in 53 byte packets. Thus we end up with a 122.069 Mbps true information rate which is about 78.5% of the nominal OC-3 capacity. And we still have not raised the issues of wasted reserved bandwidth and routing ease which were recently addressed very eloquently by Vadim Antonov when comparing connection based with packet based transport. [snip] Me again. Finally, these are the various overheads mentioned in Jim's message above: ATM AAL5 8 bytes LLC snap encap 8 bytes unused part of cell 0-40 bytes (avg. 20) --- 36 bytes (avg.) - paul

1 0

Updates, peering & flaps [Was: RE: CIDR,Sprint and the Big Guys.]
by Paul Ferguson 06 Apr '96

06 Apr '96

At 05:12 PM 4/5/96 -0800, Kent W. England wrote: > >BTW, I thought it was the updates, peerings and flaps that was the true >problem, not the absolute number of routing table entries. > > I submit that its a combination of all the above, and that the problem grows in scope as each linearly increase both in size and/or frequency. Of course, route-dampening helps on one front, but its non-trivial to code a smaller routing table when the number of routes increase. :-) - paul

1 0

Gubmint mandates of physical laws, etc....
by Mike O'Dell 06 Apr '96

06 Apr '96

O'Dell's Maxim: "Nature neither seeks nor abides your opinion." Certain legislative simeons also tried to mandate that PI be exactly 3. And all across the state in question, circles snapped-open. And now they wanna tangle with complexity theory? This oughta be fun to watch! -mo

1 0

Re: the Internet Backbone
by avg＠postman.ncube.com 06 Apr '96

06 Apr '96

Paul A Vixie <paul(a)vix.com> wrote: >Last time this term came up, I opined that there was no "backbone" any more >and that 1996's Internet had a "hairball topology." Vadim, among others, >disagreed with me but we didn't pursue the topic. Perhaps we should have. Well, "backbone" is too vague. I rather prefer to think of Internet topology as of "tiers". The nodes in upper-levels cast "cones of influence" in lower tiers. Nodes from lower tiers belonging to different cones of influence do not generally speak to each other, and so have to purchase transit from higher tiers. Note that this loose definition provides different idea of "backbone" aka the first tier, quite unlike the "defaultless core". To illustrate it let's assume there are two regional dual-homed ISPs, A and B, connected to, say ANS and MCI: ANS- --MCI | X | A--- ---B Both A and B generally have to be defaultless. But they are not in the first tier, but rather in second tier, as they have to purchase transit from first-tier providers to talk to each other. May be we should classify ISPs by miles*bandwidth of their internode circuits? >And in that sense, there is no backbone in 1996. Tier one is the "backbone". Those are providers not purchasing transit from anybody else. >Terminologically speaking, there's no discrete set of wires or routers or >companies you can point to and say, "there, that right there, that is the >Internet Backbone." Well, you can do that in practice, and be pretty certain. >We tend to reserve the term "NSP" for folks who peer at enough NAPs that they >have no default route and aren't buying transit from anybody. Ok, so here we agree :) >We tend to use >the term "ISP" when we mean someone in the packet or even the session business >who _does_ have to buy transit from somebody. Once in a while I hear the term >"backbone provider" used synonomously with "NSP" (as defined above). That's pretty common usage. Sounds much better than an-as-pee. The term for second-tier is "regional provider" and third tier is usually local providers. >I am not even going to get started (here and now, at least) on the subject of >peering politics/economics. I just thought I'd chime in on the definitions of >the words we're all using. --vadim

2 1

Re: ATM overhead
by Kent W. England 06 Apr '96

06 Apr '96

At 11:41 PM 3/24/96 -0500, Paul Ferguson wrote: >Kent, > >Have you done any statistical gathering on the overhead required to route >IP traffic in the Pac Bell ATM NAP? I'd be interested in seeing this, for >certain. :-) > >- paul > That's difficult to do on the ATM switch, and not really necessary since we can measure IP packet size any number of places and compute the ATM overhead. I have been doing some more arithmetic on the "ATM cell tax" to see if I can find out how folks get from 10% (which is the 5/53 overhead) to 35% overhead. I would really really like to see some backup for those sort of numbers -- I can't make the arithmetic work out to anything near 35% for what I think are useful assumptions. Of course, if you want to posit 100% of IP traffic with 49 bytes, but that doesn't seem realistic and you shouldn't forget that 40 of those are TCP/IP overhead. :-) What traffic mix do you use to calculate ATM overhead and what results do you get? --Kent

1 0

Re: NANOG/IEPG/ISOC's current role
by Paul Ferguson 06 Apr '96

06 Apr '96

Well, some folks at ISI have already been involved in a project similar to this, contacting folks who have been allocated bits-n-pieces of *the* TWD, 192/8. Suzanne Woolf gave a presentation at LA/IETF on the progress of 192/8 address reclamation, complete with precentages of 192/8 users who were willing to give up the allocation, users who were unwilling to give up the allocation, and so forth. I thought that she was going to put this data up on the web at ISI, but I couldn't find it this morning when I looked there. In any event, I'm not sure this is a valid project for PIER. Its really within our scope of work or within our charter. - paul At 12:38 AM 4/4/96 -0800, Craig A. Huegen wrote: > >I would recommend that the PIER group work with providers on this; PIER >would be a great organization to take the huge ACTIVE table of /24's and >mail the listed contacts for the network to offer tools, easier renumbering >methods, etc., to minimize impact to the network's customers. Once >all the mails are sent out and a semi-generous grace period is set, PIER >should recommend a date providers should stop listening to /24 announcements. >

2 1