April 1996 - NANOG - lists.nanog.org

Re: ATM overhead
by Paul Ferguson 05 Apr '96

05 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 05 Apr '96

05 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 05 Apr '96

05 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 05 Apr '96

05 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 05 Apr '96

05 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 05 Apr '96

05 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

Re: Address "portability"
by matthew＠scruz.net 05 Apr '96

05 Apr '96

Original message <CMM.0.90.0.828702375.roll(a)Junk.Stupi.SE> From: Peter Lothberg <roll(a)stupi.se> Date: Apr 5, 12:05 Subject: Re: Address "portability" > > > > > What is the general consensus of this group regarding the "portability" of > > addresses in the 204/8 and 205/8 range? > > > > > > -- > > Eric Kozowski Structured Network Systems, Inc. > > kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. > > (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" > > (800)881-0962 Voice 56k to DS1 > > > > > Portable addresses is an illusion, as it does no scale. > > Give me a call when you convinced the phone_company to make my phone number > work in > California. > > --Peter >-- End of excerpt from Peter Lothberg 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. -matthew kaufman matthew(a)scruz.net

2 1

Re: the Internet Backbone
by Paul Ferguson 05 Apr '96

05 Apr '96

At 03:34 PM 4/5/96 +0800, Vadim Antonov wrote: >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. > Well, I kind of liked the term 'blobs' [credit to Jerry Scharf]. :-) - paul

1 0

join the Internet Backbone
by Christian Nielsen 05 Apr '96

05 Apr '96

Ok, I am really getting sick of hearing, I am connected to 'the Internet Backbone' We are connected to the Internet Backbone so we are better than X and Y put together. I guess this is what happens when you get back from Interop and here all these people, uh they start with USWEST in their name, tell me and everyone else, We are connected to The Internet Backbone. So please someon,e please tell me I am correct in saying to all these not so bright people that there really is not an 'Internet Backbone' that USWest, SISNA (who now claims to be the 3rd largest ISP/NSP and still have only a T1 to MCI, and claim that is a DS3) and all these other people who think that they are connected to the internet back bone. For all that matters, I guess I can say that I am the internet Backbone because it is at my house and you all connect to me via my 28.8 modem. Oh, and for anyone is Scottsdale (sp?) AZ, go to your local Chamber. I saw them talking with a company that I can't name but probally does local phone serverice in Scottsdale, because they want a web page, connections for all their members, etc. etc. They were pretty high up. Well, thanks for all your help. because I wanna be an isp :) Now where did I put that Lart. Christian Nielsen Vyzynz International Inc. cnielsen(a)vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian(a)Nielsen.Net BOFH - cnielsen(a)one.dot PS :)

4 6

CIDR,Sprint and the Big Guys.
by Christian Nielsen 05 Apr '96

05 Apr '96

I think we all agree that CIDR is a good thing, I have no problems with it and feel that we should use it as best we can. The problems that I see, yes I know this has been said before, it is getting harder and harder for the little guy to get IPs from the Nic. Now that Sprint is saying that you now need a /16 to route over their network, I don't see the nic just handing out /16s like they did with the /19 or before that the /20s etc.. And Just because I have nothing else to do, except work, sleep, work, internet, eat, work, sleep, I did some looking around. [21]/export/home/c/cnielsen> whois 208.0.0.0 Sprint (NETBLK-SPRINTLINK-BLKS) Netname: SPRINTLINK-BLKS Netblock: 208.0.0.0 - 208.3.255.0 Here now shows that Sprint is getting a /15 from the nic and that they can now server more customers, move their ips around with little problem, etc. But what about some other ISP? Can they get a /15? Nope. But I bet you that if Sprint wanted to or even MCI for that matter, they could get a /14 or a /13 from the nic. How can we solve this problem? How can we make sure that everyone has equal access to IP addresses to make IP addresses usable around the Net, save on router memory etc? This is how I would do it. Move into the 206.10.0.0 - 206.15.0.0 Any ISP/NSP that can provide a good network outline, showing not only how they plan to put into pratice but show their current setup, locations, etc. will be assigned a /16 in the range above. That would give about 1200 ISPs /16s. Now, to make sure they are being conservative with their networks, routing tables, CIDR, etc. Explain to the ISP that the only way they are going to get a /16 is if they renumber their whole network. This will return a lot of larger /20 and above address space to the nic and reduce the size of the routing table on the net. Now, why can't something like this be done? Trust me, If you gave me /16, I would have all my customers re-number, re-number all my hosts, etc in about 6 months, which is about the timeline I would bive. But than again, we can go along as we do, the larger keep getting larger and the rest of us have to fight for IPs. ok, now off the soap box. Christian Nielsen Vyzynz International Inc. cnielsen(a)vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian(a)Nielsen.Net BOFH - cnielsen(a)one.dot PS :)

4 4