- Test - lists.nanog.org

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

04 Sep '96

Vadim, My understanding is that RSVP is targeted to solve the problem of offering services such as audio/video conferencing, audio/video streaming such as radio/television, and telephony services on the Internet and private networks that use IP. A "problem to start with" is offering these services in the current Internet does not yet work. Cheers, peter >>>---------- My question is -- what exactly resource reservation is going to solve? Is there a problem to start with? --vadim

1 0

Re: :)
by Sean Doran 04 Sep '96

04 Sep '96

| We'd be happy to change this mapping to some other hostname (or CNAME | the inverse address), if the Sprint folks would prefer something | different :-) Well, I wanted to name our private peerings after the seven deadly sins, but maybe "somerouter.sprintlink.net" is a good choice until the names are settled on this side. That'll happen when the tactical build-out we began a week and a half ago is completed in a few days. Meanwhile, 206.157.77.90 is sl-chi-15-H1/0-T3.sprintlink.net (anger) 206.157.77.34 is sl-dc-1-H5/0-T3.sprintlink.net (sloth) and 206.157.77.66 is sl-stk-1-H9/0-T3.sprintlink.net (pride) which are subject to move, and the mapping for the remaining RRs are not nearly as firm... Of course, I like Enke's suggestion too. :-) Sean.

1 0

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

04 Sep '96

| Whenever you discover that in your design you risk [...] | [...] taking the entire box down [...] it is time to | seriously consider whether you've made the right design decisions. This is a truism. Sean.

1 0

RE: Agenda for next NANOG
by Peter Ford 04 Sep '96

04 Sep '96

Looking at it strictly from a technical level, there is little difference between a private interconnect and the connection between an ISP and their upstream provider if they have one. (we might consider debating this assumption especially in terms of scale :-)) One might as well ask if ISPs are willing to publicly display their packet drop rates where they buy connectivity from their upstream providers at the same time one is asking MCI, Sprint, UUNet and ANS for their interconnection drop statistics. Might it be easier for a customer of an ISP to get this kind of data from their ISP? Or not? Cheers, peter >>> ---------- I wonder if this is something involved parties (MCI, Sprint, UUNet and ANS) are willing to talk about, given that I've noticed some degradation on performance across some of these private interconnects already.. (and it's only been couple of months since they came online!) I understand that these are private arrangements between involved parties, but given their importance, it would be a great service to the community if the involved parties could share some information. -dorian

4 3

RE: MFS WorldCom/WilTel/LDDS
by Sean Doran 04 Sep '96

04 Sep '96

| My understanding is that RSVP is targeted to solve the problem of offering | services such as audio/video conferencing, audio/video streaming such as | radio/television, and telephony services on the Internet and private | networks that use IP. | | A "problem to start with" is offering these services in the current | Internet does not yet work. Um, this comes as a bit of a surprise to me. My understanding of why I'm glad Sprint is participating in the VON coalition is that telephony services on the Internet *do* work, proof by existence. The services are not optimal, but they are no longer toys, either. Moreover, the various people doing audio and video things are not going to be in the realm of "interesting experiments" forever, and hopefully not for very long. RSVP is not a gating requirement, nor is it a magic bullet. The key factors in making any point-to-point realtime services available in the short run are: 1/ adequate response to congestion on the part of the transmitter (i.e., back off when acks are delayed and slow-start when they're missing, just like TCP only without the retransmissions), 2/ infrastructure improvement, notably i: better buffering and buffer-management in routers, so that delayed acks can be seen at all, rather than the chronic loss we experience now, ii: more bandwidth, iii: more routing stability, to eliminate the worst problems associated with flutter and fluctuation, 3/ software software software, to make point-to-point realtime easy and cheap to use, and to more useful (for instance, by letting IP networks carry PBX-to-PBX voice as a voice-network bypass, or having means to allow someone with an Internet-connected computer call out to someone with POTS, or vice-versa, at roughly local rates), 4/ doing all this quickly enough not to get bogged down in anything other than how to engineer things rapidly and well enough to be usable. Multicast, whether point-to-multipoint or multipoint-to-multipoint, is a more difficult matter, in part because the multicasting facilities in IPv4 are awkward for enormous use (think of millions of multicast groups of from a handful to several thousand receivers, and multiple transmitters trying to reach exactly the same audience. think of a few thousand pps too. that helps.). RSVP is not really anything of a help with respect to either unicast or multicast traffic, except perhaps as potential economic backpressure, since the resources that need reserving typically amount to buffering and a stable route, perhaps more than sheer bandwidth. At least two vendors are working on interesting, probably-useful and radically different means of addressing this sort of thing without resorting to RSVP or anything very much like it, and certainly nothing that aspires to work independently from routing. Again, neither the absence of RSVP or non-committee-generated philosophical alternatives will stop people from doing point-to-point or even various forms of multicasting of real-time information, and expecting old things and new things to work. Personally, I like seeing things blown apart by new applications. It doesn't do much for my sleep cycles or necessarily for the happiness of the base of users who remember what the Internet was like before the enormously popular WWW was unleashed, but added utility is imho a hugely important part of the Internet. The trick is how to add utility without wrecking the whole system, or indulging in wasteful faddishness to support the egos of people who invent interesting but not very workable ideas... Sean.

1 0

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 04 Sep '96

04 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