- Test - lists.nanog.org

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

04 Sep '96

Peter Ford wrote: >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. Resource reservation is nothing more than a prioritization scheme. If there's no sufficient resources to share, doling it differently does not change the fact that resources are not available. All you get by doing resource reservation is to trade packet loss to denial of service. If you think about it, a properly designed voice protocol would sustain 30% packet loss w/o much trouble (say, if you split sample bit stream into nibbles and send bit 0 in a high-priority packet, and bits 1-3 in regular-priority packets); whereas a voice network which is not available 30% of time is very close to useless. >A "problem to start with" is offering these services in the current >Internet does not yet work. Knowing for sure how Internet backbones are provisioned i can say that the solution is in entirely different plane. In fact, if you allocate resources to Internet within the same overcommitment margins as are commonly found in POTS you'll get _better_ quality of service. Without prioritization, that's it. --vadim

1 0

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

04 Sep '96

Curtis Villamizar <curtis(a)ans.net> writes: > There are routers that handle {LS}SRR at near full speed. Stuffing it > on the broken path in is a bug. Fast-path/broken-path > is just a bug. I'm not sure I agree, particularly in the case where "broken-path" involves delegating work to another processor. I will agree with you that the fast switching scheme in current IOS is gross, however it was expedient, and is the reason there are so many DS3 networks operational today. Remember that prior to 10.2-viktor it was much worse... The fact that one fast-path/slow-path scheme is broken in several subtle ways does not really convince me that it's a bad idea in general. In particular, when we're dealing with the sorts of time budgets needed to support multiple OC48s per card, while _I_ would love to have a single path and might be willing to live with reduced port-density (clever secondary-circuit wiring, for example) to avoid running too close to per-packet time-budgets, other people might convincingly argue that if one can determine in advance that drops will happen if a particular datagram is fully processed, and the combination of determining that and delegating the work to another processor falls within the time budget under bad-case to worst-case conditions, it's a good idea to have multi-path forwarding. So, yes, simplicity is good and easy to diagnose. Unfortunately, when the diagnosis is a simple "you haven't got enough processing power to handle your traffic pattern using a single path", forwarding-path simplicity is one of the things that needs evaluation. Of course, I am also from the school of thought that someone blasting a huge amount of worst-case traffic on one interface should never affect normal traffic across that and especially not other interfaces. That school doesn't like the thought of not being able to handle a full OC-12's worth of offered traffic on an interface because someone is jamming a large fraction of that bandwidth worth of Christmas-tree packets at someone's router. Discovering that routers X handle Y at "near full speed" always worries me. Consequently, I worry alot. :-) Sean.

2 1

"Building the Internet backbone"
by Stephen Balbach 04 Sep '96

04 Sep '96

"Building the Internet backbone" Take a virtual tour of a busy Network Access Point by George lawton SunWorld Online. http://www.sun.com/sunworldonline/swol-09-1996/swol-09-nap.html Abstract The Internet, of course, consists of many networks strung together. The Internet's skeleton is made up of high-capacity trunk lines maintained by telephone companies at sites called "NAPs." This article outlines the role of NAPs, and profiles Pacific Bell's NAP in particular. (2,700 words) --- Stephen Balbach "Driving the Internet To Work" VP, ClarkNet due to the high volume of mail I receive please quote info(a)clark.net the full original message in your reply.

1 0

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

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

03 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