September 1996 - Test - lists.nanog.org

Re: Agenda for next NANOG
by Sean Doran 04 Sep '96

04 Sep '96

Curtis Villamizar <curtis(a)ans.net> writes: > This is an interesting problem and actually close to solvable at the > IP level. I'm sure you are familiar with PPP LQM. Take out the PPP > part and keep the LQM packet format and local storage. Keep one LQM > struct per ARP entry on a bcast or nbma interface (such as an ATM > NAP). Count packets used by each ARP entry and update SNMP and the > LQM entry as you would in PPP LQM. Occasionally (once a second is > fine) send an LQM packet summarizing what has been sent. This is a very good idea. You might want to hand it over to your vendor before I hand it over to mine. :-) Sean.

3 2

Re: Access to the Internic Blocked
by Sean Doran 04 Sep '96

04 Sep '96

Curtis Villamizar <curtis(a)ans.net> writes (to Vadim Antonov): > Oh come on. Like they're not going to get caught stuffing an entire > T1 with LSRR packets. Face it. You're grabbing at > straws. Can I grab at one too? I'd love to see LSRR (and SSRR) dead because it slows down single-path forwarding considerably, and complicates fast-path/slow-path systems in gross ways for what I believe is minimal added utility. Some folks may have run across more uses for one or the other that involve more than 'traceroute -g' or 'telnet @foo:bar', both of some utility, I suppose, but one is easily replaced with application-level proxying, and the other is just weird. Or vice-versa. Of course, I don't have a religious feeling about this, since I try to persuade my vendor(s) to supply routers which can handle tiny Christmas-tree packets (those that are fully decorated with options) at line speed without loss. Then again, I work for a company with deep pockets that can afford what it takes to buy per-packet time budgets that can satisfy that kind of design criterion... (Others may want to consider encouraging people to keep fast Internetworking cheap by using things like MTU discovery and getting rid of things like IP options) Sean.

2 1

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