August 1995 - Test - lists.nanog.org

Re: ATM thruput
by woody＠zocalo.net 04 Aug '95

04 Aug '95

gcook(a)tigger.jvnc.net (Gordon Cook) writes: > Bill, would you please define what you mean by non transit > peering and explain what the advantage of such would be? Time for ASCII art (oh nooooooo!)... +---------+ +------------+ +----------+ | | | | | | | Net99 +----+ MAE West +----+ Sprint | | | | | | | +----+----+ +-------+----+ +-----+----+ \ : \ \ : \ \ : \ +----------+ +-------+------+ +---+---+ +----+-----+ | | | | | | | | | Aimnet +-----+ Mainstreet +------+ PCH +------+ Zocalo | | | | | | | | | +----------+ +-------+------+ +-------+ +----+-----+ / / / / / / +-------+------+ +-----+------+ | | | | | Mainstreet | | Zocalo | | Customer | | Customer | | | | | +--------------+ +------------+ Okay, that's me over on the far right-hand side. I'm paying for transit through Sprint. I'm paying a nominal flat-rate to hold up my share of the facilities for my connection into PCH, and I'm not paying anything to any of the other PCH members. PCH maintains a no-settlement peering policy by not having members do transit across it... To use the example above, Mainstreet advertizes a route to themeselves and to their customers to all the other PCH peers, but they don't advertize a route to Net99 or Aimnet. Likewise, I advertize routes to my customers, but not to Sprint. Thus any traffic I have for any PCH peers or their customers goes directly to them, but anything to anyone who's not a PCH peer goes out through my paid-transit connection. So what we'd like to do is peer with larger ISPs. We know that individually we're small-fry, and that we'd never stand a chance of getting Sprint, MCI, etc. to join on the same basis as little ISPs, but collectively we can put one router on MAE West and potentially one on the S.F. NAP. What we'd like to do is offer up all our routes together on that router for peering with other ISPs at the MAE, but since we'd still be smaller than most of them, even banded together, we'd offer to give up transit (i.e. if MCI agreed to peer with us there, we'd agree never to dump traffic _through_ MCI to MAE East; we'd only use MCI to reach MCI's customers) in exchange for a no-settlement peering agreement, just as we use among ourselves. Why this is _should_ be attractive to larger ISPs :-) is that it means they themselves should actually have to carry less traffic. If they choose to peer with us, they can dump traffic directly into each of us via PCH. If they don't peer with us, they have to use a transit carrier (Sprint to reach me, or Net99 to reach Mainstreet, in the example above) and pay a settlement to that carrier. So is anybody up for it, or am I another one of those raving loonies that make mailing lists so annoying? -Bill Woodcock ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

2 1

Re: ATM thruput
by Sean Doran 03 Aug '95

03 Aug '95

Gosh, but who would be interested in T1 access into a NAP, unless their arm was being twisted via some financial arrangement into being at a NAP-of-little-current-value? ;-> (Except maybe someone sold on the idea that bringing a T1 into a NAP is a good way to get global connectivity...) Sean. (personally curious) - -- Sean Doran <smd(a)clock.org>

5 5

Internet Security tutorials this fall
by stonem＠farnet.org 03 Aug '95

03 Aug '95

Together with CERT, (Computer Emergency Response Team), FARNET is again hosting Internet Security tutorials. Internet Security for Managers is a 1/2 day overview of security issues, approaches and strategy. It will be Sept. 6, and Nov. 16th. Internet Security for System and Network Administrators is a 1 day technical tutorial. It will be Sept. 7. Both will be held in Washington DC. See the FARNET home page (http://www.farnet.org) or send to seminars(a)farnet.org for more information. Regards, Martha ************************************************************************* Martha Stone-Martin Program Director FARNET...."The Internet Builders" (617) 273-5423 stonem(a)farnet.org

1 0

Re: ATM thruput
by woody＠zocalo.net 03 Aug '95

03 Aug '95

bmanning(a)ISI.EDU writes: > The 400 local ISP's in the NAP metro area who want a common > exchange point among themselves. They then make a great > collective which can bargin with a long-haul carrier for > transit. That's why we pulled the PCH together last winter, for California-area ISPs... T1 access to the SF NAP wasn't available, so we did it all through a frame cloud. It's basically all just BGP through Ciscos. Seems to work fine. Just like a big peering point, but little. :-) It was originally our goal to use a collective-bargaining approach to try for non-transit peering with MCI, Sprint, etc. over MAE West, since we're on the MAE West fiber, but we haven't gotten around to it yet, and I'm afraid it may be too late, now. We've all already got long-haul transit taken care of, though, and we're just doing (and just looking for) non-transit peering, which is probably the only thing that would still make anyone listen to us. In case anyone out there is in Pac Bell country and interested in joining, we only charge $250/12K CIR/year, and you can get more details by mailing me or Chris Alan (calan(a)electriciti.com) -Bill Woodcock ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

2 1

Re: ATM thruput
by kwe＠6SigmaNets.com 02 Aug '95

02 Aug '95

At 7:49 AM 8/2/95, bmanning(a)ISI.EDU wrote: > >Kent, the term "full bandwidth" should be clarified a bit. Are we talking >the 34Mbps limit for a DS3 connection or the 146Mbps for an OC3? > >--bill I should have mentioned DS-3. OC-3 tests aren't done. --Kent

2 1

Re: root name servers
by Havard.Eidnes＠runit.sintef.no 02 Aug '95

02 Aug '95

> The whole point of hijacking the root domain servers is that it > turns DNS from a centralised system into a more distributed > system where cooperation is essential. Umm, let me see if I can phrase this gently.... This whole idea of hijacking the root domain must be one of the ideas I've seen recently which is fully at odds with one of the major points of what I perceive the Internet is all about. If you decide to set up your own group of root name servers with a different naming and registration policy than the current root, you are of course free to do so (nothing will prevent you). However, this will create a totally separate DNS name space from the single name space we have today. If I am not much mistaken, a given name server *cannot* look up names in more than a single name space, so you end up creating two different "universes". Depending on how you populate your local name server's cache with root name server hint information, your name server will either end up being able to look up names in one or the other of these two separate name spaces but not both. (Yes, there are "technical reasons" with the current DNS protocol that make this so, if I've not totally misunderstood things.) Aside from causing massive confusion (people really do have a hard enough time figuring out how to configure DNS semi- correctly with only a single name space at hand), this conflicts with the goal of *connectivity*, i.e. that I am able to e.g. send e-mail to anyone else who is connected. With two or more (shudder) separate name spaces I will claim that this will not in practice be possible. The "distributed system where cooperation is essential" is what we have today: you pick your name (which isn't already taken) under a given other name, have it delegated to you and thereafter you have full autonomy over your own name space. The "cooperation (which) is essential" is what the current caretakers of the root name servers are doing today. 1/2 ;-) Sorry, I do not see how you can both "hijack the root name servers" and acheive full connectivity. If you want to sacrifice full connectivity (or an approximation thereof), you are of course free to go ahead and see how large a following you could gather. Regards, - Håvard

1 0

Re: EP.NET ???
by Havard.Eidnes＠runit.sintef.no 02 Aug '95

02 Aug '95

> > Personally I think that this is actually a value-subtracted service, > > as the EP.NET organisation does not run the named boxes, or the > > exchange points. > > > > It would be much more helpfull the the interfaces that faces the NAP > > and another provider where following each providers naming > > conventions, and had a domain-name that would point the users to the > > organisation that actually operates the boxes. > > Yes, that is the desired goal, however some sites are not > willing or able to do so, so there is a default case where a > name is available. (There are some exchange points where no > forward is registered, which can be a hassel) The existence of a forward mapping is not a necessary technical precondition for you to insert a reverse mapping which points in the right direction, i.e. at the organization operating the boxes. However I also have trouble seeing why any ISP would willingly decline to register it's boxes in the DNS. I fully agree with PL that introducing EP.NET into this is value- subtraction, in that it will just add unneeded confusion. - Håvard

4 4

Re: NEW POLICY ON INTERNET DOMAIN NAMES
by Dave Crocker 02 Aug '95

02 Aug '95

At 8:30 AM 7/28/95, bmanning(a)ISI.EDU wrote: >It really does not matter, as long as at least one is made available. As long as we're at it, let's carve of 4. Documentation often needs more than one. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker(a)brandenburg.com

1 0

Re: US Domain -- County Delegations
by Sean Doran 02 Aug '95

02 Aug '95

>i would fear for the interconnects if all seven root servers got 600/sec Why? 5 minute input rate 26121000 bits/sec, 13430 packets/sec 5 minute output rate 19862000 bits/sec, 12327 packets/sec That's one of two connections to a particular (busy) interconnect at a pretty quiet time (22:30 EDT Tuesday). We see 15-minute periods of ~35Mbps inbound these days on the same link. The interconnects that are based on FDDI and DEC FDDI switches are working *beautifully*. Admittedly the bridging happening here and there to accomodate slow connections has occasional hiccups which cause nasty side-effects, but that's one of the very few flaws in the whole scheme of the MAEs, one NAP, and the special hack done at another NAP. Say, does anyone know if ATM NAP gear can handle > 20Mbps yet? Sean.

3 2

ATM thruput [was Re: US Domain -- County Delegations]
by kwe＠6SigmaNets.com 02 Aug '95

02 Aug '95

At 6:40 PM 8/1/95, Sean Doran wrote: > >Say, does anyone know if ATM NAP gear can handle > 20Mbps yet? > > Sean. Sean; I have recent preliminary test results of the cisco AIP across the Newbridge 36150 (which is the PacBell NAP configuration) that show nearly full bandwidth TCP throughput. The Kentrox ADSUs are much improved, but results are preliminary. I will present more about this next Tuesday at the PacBell NAP Users meeting in San Ramon, CA, at the next NANOG and eventually on the PacBell NAP Home Page. --Kent

2 1