- Test - lists.nanog.org

RE: MFS WorldCom/WilTel/LDDS
by Vadim Antonov 03 Sep '96

03 Sep '96

Peter Ford <peterf(a)microsoft.com> wrote: >Metcalfe certainly is not the first, or the last, to call for >"reservations" and last time I looked a lot of the work in the IETF is >centered on this area. This does bring up the interesting point of >will/should the Internet business model change to support reservations. Peter, i nave no problems with resource reservation or charging based on resource reservation as a business model. It is perfectly valid. What i have problem with is that nobody ever managed to explain how a data network of size of Internet providing resource reservation can be built. The problem is that in "fat state" schemes (i.e. keeping per-connection state in gateways) consistently yield linear growth of state in gateways at exchange points as function of network size. Which, given exponential growth of Internet is not going to fly. Remember that Moore's Law has smaller exponent built in. I wouldn't even dwell on differences in session arrival patterns between POTS and Internet which make all Erlang-based telco technology to be totally useless to handle Internet kind of traffic. I feel sorry for folks who work on RSVP et al, they're very much like those brilliant minds who spent their lives improving perpetuum mobiles. Some of the devices were truly amazing feats of engineering. No amount of technical cleverness can deal with the fundamental scaling problem. It's like the second law of thermodynamics. >Let's assume some kind of "promise" beyond the current best effort service >is offered. Do you really believe this will not be based on usage? I know that application targeted by resource-reservation can happily work without. There are numerous proofs by existance. My question is -- what exactly resource reservation is going to solve? Is there a problem to start with? --vadim

1 0

Re: [fwd] Protocol Action: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP
by Sean Doran 03 Sep '96

03 Sep '96

[RFC1466bis->BCP] Wow. I seem to have missed a series of obituaries. Where should I send condolences? Sean.

1 0

Re: Agenda for next NANOG - interest in domain names?
by Sean Doran 03 Sep '96

03 Sep '96

Well, frankly, I don't care one way or another, as boring topics can be slept through. :-) OTOH, I have some concerns about the increasing trend of people who have never been to a NANOG meeting requesting time to make presentations, hold panels and so forth. This will probably surprise everyone. Sean.

1 0

RE: MFS WorldCom/WilTel/LDDS
by Peter Ford 03 Sep '96

03 Sep '96

All of them do, to my knowledge. It's Metcalfe et al who are calling for change in the direction of resource reservation and per-connection charging. --vadim Vadim, Metcalfe certainly is not the first, or the last, to call for "reservations" and last time I looked a lot of the work in the IETF is centered on this area. This does bring up the interesting point of will/should the Internet business model change to support reservations. Let's assume some kind of "promise" beyond the current best effort service is offered. Do you really believe this will not be based on usage? peter

1 0

Strange Routes
by Vadim Antonov 03 Sep '96

03 Sep '96

Enjoy: % traceroute www.unitedmedia.com traceroute to unitedmedia.com (204.240.178.10), 30 hops max, 40 byte packets 1 140.174.86.10 (140.174.86.10) 137.582 ms 125.193 ms 126.528 ms 2 gw-tlg (140.174.86.2) 130.345 ms 126.407 ms 158.074 ms 3 tlg-cust-link.tlg.net (140.174.199.2) 134.497 ms 126.107 ms 127.23 ms 4 ln3_gw1-sj-tlg_mv.tlg.net (140.174.101.5) 204.124 ms 255.635 ms 194.128 ms 5 mae-west.tlg.net (198.32.136.22) 183.47 ms 223.452 ms 206.021 ms 6 905.Hssi3-0.GW1.SCL1.ALTER.NET (137.39.133.89) 204.209 ms 266.514 ms 278.43 ms 7 Fddi6-0.SR1.SCL1.Alter.Net (137.39.19.36) 222.749 ms 330.877 ms 490.011 ms 8 Hssi2-0.BR1.NUQ1.Alter.Net (137.39.103.6) 380.718 ms 234.135 ms 436.153 ms 9 mae-west.psi.com (198.32.136.23) 473.437 ms 287.215 ms 305.98 ms 10 ne.sc.psi.net (38.1.3.1) 500.152 ms 367.262 ms 430.873 ms 11 rc8.northeast.us.psi.net (38.1.21.8) 370.318 ms 509.708 ms 386.508 ms 12 38.4.218.4 (38.4.218.4) 461.314 ms 443.618 ms rc8.northeast.us.psi.net (38.1.21.8) 507.873 ms 13 unitedmedia.com (204.240.178.10) 447.827 ms 335.4 ms * % --vadim

3 2

Re: Access to the Internic Blocked
by Geoff Huston 03 Sep '96

03 Sep '96

Vadim writes, >On itself, LSRR is a godsend to hackers (i can think of about >a dozen of very nasty attacks using general LSRR). The only >useful application for it is traceroute. > >Why don't router vendors provide an option to turn it >off for everything but ICMP ECHO? Personally I find this an excellent suggestion. g

3 2

Re: Agenda for next NANOG
by Guy T Almes 03 Sep '96

03 Sep '96

Randy, There is a cluster of closely-related variants on the issue you raise: [] to what extent does a given exchange point (NAP/MAE/etc) constrain the performance that a user sees (in what a user thinks of as end- to-end). For example, an FTP could flow at 800 kb/s for a given pair of users, except that MAE-north is congested, so the FTP can only flow at 400 kb/s. [] to what extent does a given exchange point constrain the performance that a provider sees (in what a provider thinks of as end-to-end). For example, a given pair of backbones could sustain 20 Mb/s over a private interconnect with acceptable packet loss, but can only sustain 10 Mb/s over the Altoona NAP. >From different perspectives, each of these notions of end-to-end has meaning. Would you want to consider one or the other or both in the panel? -- Guy At 01:11 PM 8/30/96 PDT, Randy Bush wrote: >>> Analysis of Actual End to End Performance accross the NAPs/MAEs >> An excellent topic, to be sure, but how do you propose that this be >> measured? > >And there's a subject for a NANOG panel in itself. > >I can think of some interesting experiments that would involve cooperation >of multiple peers. But there are folk far better based in measurment than I >who might suggest some fun stuff. Guy, Steve, ..., this is your cue. > >randy >

2 1

Re: Agenda for next NANOG
by Guy T Almes 03 Sep '96

03 Sep '96

Paul, The relevant BMWG work here is within the IPPM effort. The email list is ippm(a)advanced.org with the unsurprising ippm-request(a)advanced.org to join/unjoin. -- Guy At 01:29 PM 8/31/96 -0400, Paul Ferguson wrote: >At 01:11 PM 8/30/96 PDT, Randy Bush wrote: > >>>> Analysis of Actual End to End Performance accross the NAPs/MAEs >>> An excellent topic, to be sure, but how do you propose that this be >>> measured? >> >>And there's a subject for a NANOG panel in itself. >> >>I can think of some interesting experiments that would involve cooperation >>of multiple peers. But there are folk far better based in measurment than I >>who might suggest some fun stuff. Guy, Steve, ..., this is your cue. >> >>randy >> > >... And it might even be nice for someone who is active in the >IETF Benchmarking Methodology WG (bmwg) to participate. > >[ref: http://www.ietf.org/html.charters/bmwg-charter.html] > >- paul >

1 0

Re: Agenda for next NANOG
by salo＠msc.edu 03 Sep '96

03 Sep '96

> Date: Fri, 30 Aug 1996 15:59:23 -0700 (PDT) > From: Michael Dillon <michael(a)memra.com> > To: nanog(a)merit.edu > Subject: Re: Agenda for next NANOG > [...] > What would it take to set up a couple of Alphas, routers and zero-mile > T1's in a portable testing kit to go around from NAP to NAP and run tests? > [...] > Such > machines could run a full suite of tests including FTP'ing large files, > downloading complex web pages (i.e. multiple images) as well as the lower > level things like ping tests. > > This kind of test would provide useful numbers that customers can > understand as well as point out problem areas that a NAP operator might > need to investigate. And with co-operative NAP peers, the same test kit > could be used with T1's out to various locations that feed into the NAP so > as to run the same tests across the peer's routers and lines. > > Would this kind of testing reveal any useful information that could not be > gotten from examining router stats? Actually, it would be nice if this "portable test kit" were actually an optional board for a router. You could, for example, stick the "portable test kit" board in a router and then test at will. We also tried to explain to our ATM tester vendors that we wanted ttcp implemented in the ATM tester. Some understood, some didn't... -tjs

4 4

RE: MFS WorldCom/WilTel/LDDS
by Jim Browning 02 Sep '96

02 Sep '96

>From: Sean Donelan[SMTP:SEAN@SDG.DRA.COM] >Sent: Monday, September 02, 1996 3:22 PM >A current problem Internet is line capacity only comes in a few different >sizes; small (DS0), medium (T1), large(T3), and extra-large (OC3c). >One reason ISDN is extremely popular is its just a bit bigger than >a DS0, and a lot less than a T1. Because the next step is so large, >customers tend to stay with their current size long after it stops >fitting their needs. It's possible to provision ATM circuits at pretty much any capacity a customer wants, from 1Mbps to 155Mbps, without having to swap-out hardware in order to bump up the speed. Of course this also makes new services available which would otherwise be impossible to manage (single event bandwidth increases, anyone?) >So-called "usage-based" pricing is just a klunky work around to the too >big a step between sizes problem. Customers want something just a bit >bigger than a T1, but don't want something 28 times bigger. Usage-based >pricing lets customers use something just a bit bigger even though the >provider uses a massive pipe to deliver it. This is frequently true, although there are specific situations where usage based pricing is attractive for its own sake, for instance as backup for a fixed price circuit. >I suspect when Cisco's 11.2 traffic-shaping hits the streets, you >will be able to buy more "fixed-rate" Internet connections at the >in-between line-speeds providers previously only offered on >usage-based pricing plans. Sure, some providers may resist initially. >But someone will break ranks, and the others will eventually follow. Those ranks have already broken, at least in territories we serve, and there was no need to wait for new software... ;-) -- Jim Browning <jfbb(a)atmnet.net> P.S. Will it help avoid the IP <==> ATM religious battle I may have just started if I lie and say I am unsubscribing for the next week or so?

1 0