nanog mailing list archives
RE: Is anyone actually USING IP QoS?
From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Tue, 15 Jun 1999 19:20:43 +0400 (MSD)
Aleksei, I agree that you can solve one-to-many type of applications by smart caching. Though the problem now is how much you want to spend on caching, where you cache and would it scale well.
I have meant _replication on the fly == multicasting_. You can build NEW MULTICAST network over the internet, and begin multicasting just from the data source. This means _new router features_ (buggy and odd for now), new routing protocols (such as PIM, buggy and odd), etc etc - a few years (and may be the horse will die BEFORE you'll have success). Or you can try from the other end - doing replication on the fly, and convert existing UNICAST data streams to the multicast if (and where) it's nessesary only. Just as WWW caching, you'll have results from the first week, and you can do ot one the customer's eddge, on the data-source eddge. I am not shure if the first approach is worst or not, nut for a few years there is attempts to build multicast network over the whole internet - and it have not eny success except a few of pylot projects. Compare RealVideo auditory and multicast auditory for now... And why don't try anpther approach. Alex.
And I'd like to point that multicast tries to solve not only one-to-many problem (eg. streaming video) but other scenarios as well. What might be alternative for many-to-many apps? How to scale such applications? As regarding QoS, I don't think that we'll see a protocol that will cover Internet as a whole. In my mind protocol driven QoS is intra-AS or intra-ISP issue and crossing AS boundaries is regulated by SLA which is hardly dynamic thing ;). Though some statically defined QoS filters might be installed. QoS wouldn't create more bandwith but rather make billing easier. That's my take on this. Regards, Grigorij-----Original Message----- From: Alex P. Rudnev [SMTP:alex () Relcom EU net] Sent: Tuesday, June 15, 1999 5:44 AM To: O'Flaherty, Douglas Cc: nanog () merit edu; 'steriley () microsoft com' Subject: RE: Is anyone actually USING IP QoS? // Sorry, if it's not for nanog forum, I can drop it's address from this // discussion.Alex, steve: I know this thread is effectively dead, but I'm just catching up andenjoyedthe discussion very much. It's NANOG so it isn't surprising therewas littlediscussion of the edge of the networks. No one mentioned critical other functions for multicast and QoS:datadistribution and interactive services. The growth in broadband isputtingnew services (and telephone is the simpliest) on the edge of thenetwork.Data distribution is a model starburst is working on. I think thedemand forit will grow exponentially. As the broadband world grows there are real oportunities forinteractivecontent placed near the edge of the network. This can not becentrallyplaced because of latency requirements for interactivity. Thearchitecturerequires 1000s of servers with pratically identical data on them.It's muchlike a proxy pre-fetching data. The problems is there is lots of it (100-500G). Multi-cast on public or private net is the logical wayto do getthe data there.You areright about multimedia, but I am not sure about multicast. Russions are saying - if you see the banner _elebhant_ on the cell with the monkey in the zoo - don't believe to trhe banner. Just there. Multicasting is the beautiful idea, nice banner. But look on the real world. There is MULTIMEDIA ALREADY - I can get CNN TV, I can get different music, I can look on the shattle lanch in real time - withouth multicasting. There is already EXISTING MULTIMEDIA in the network - RealVideo and StreamVideo/on/demand. Not I have a question. No doubt, if 1000 customers ask RV stream from the CNN, the network fail down (or exactly server refuse to do it). This mean _this data have to be REPLICATED on the FLY_. There is a few different ways to do such replication. One way is MULTICASTING. It was developed for the LAN networks (because there is not other way to replicate data over the ethernet) and it's the only way to get multicast in the LAN if you need strong replication. But in real life, LAN network are not bottlechecks for this multimedia - if all RELCOM's employees ask RV CNN at once, our LAN networks can hold this traffic withouth big problems (128Kbit * 100 = 12,8Mbit - less than 1 100BaseTX ethernet!). The other way is CACHING. Caching on the fly or caching with the short time to live. There is two differences between this ways. Multicasting need another routing scheme, another address scheme, it's really ONE ANOTHER network. Caching need... no changes for the customer, just catch request on the fly (as WWW CACHE ENGINE by CISCO do for the WWW requests) and CACHE data on the fly). Now compare. One scheme need one another set of aggreements, one another set of configurations, etc etc... It's the only way for the DENSE MULTIMEDIA (if you need TV for the 1000 customers at one LAN at once, for example). Another way need one more protocol (such as WWW-CACHE-CONTROL protocol by CISCO, sorry I don't remember RFC number for it) but for some MultiMedia requests (RealVideo and StreamVideo are enougph for now), no aggreements, no additional configurations schemas, no changes for the customers and/or service providers. Guess what's better. And in real live, we have not multicast in the Internet. We have some SHOWS, but use RVplayer or other _request and send_ systems filled up by the information and music. And if someone propose effective cache engine for this streams - he'll be winner, not multicasting. Of course, no one prevent this cache engine from doing multicasting locally. What's about QoS - first, you need something simple oer the whole Internet. Then you can speak about RSVP and so on - if don't WDM kill it for this future time. Alex. -----As these new services are offered the need for QoS in the last milewill bemore critical. Some of these apps require minimal latency or strictpacketorder. There is a strong future for QoS, but edge networks willrequire itmuch more than the Internet. I work for one of the new interactive companies. The lack of goodtools andprotocols is keeping me up at night. doug douglas o'flaherty dir ops & support arepa.com -----Original Message----- From: Alex P. Rudnev [mailto:alex () Relcom EU net] Sent: Tuesday, May 18, 1999 5:17 AM To: Steve Riley (MCS) Cc: nanog () merit edu Subject: RE: Is anyone actually USING IP QoS? I must agree and disagree. RSVP is dead protocol - it's enougph to imagine how different ISP can negotoate about RSVP service, and (in addition) read RSVP protocol itself... On the other hand, why don't provide QoS in the non-overbookednetwork.It's not difficult to install PRECEDENCE queue-control, just asnegotiateabout some classes of service, to prevent short network bursts from disturbing multimedia streams. I'd like to ask one more question. Multicast, If we project multimedia services from the scratsch, you have a few different choices. For example, you have RealVideo server. I ask youabgour RV stream. Ok, you send packets with DST=MY_ADDRESS. Then someone else send second request. Why (WHY) can't RV server addsecond DST address into the packet? Why can't you use the same,unicast,address space for multicast services. I mean - first way was (was) to use existing address space formulticastmultimedia, and add some mechanism (such as replicators) to hide themechanisms from the end user. No one bother if some RV-CACHE servercatchhis request and use his own replicator to organise multidemiastream.Second way was choosen - to use another address space for themultimediamulticasting. Result - you see - Internet have not (HAVE NOT)multimediamulticast at all. No, some ISP have internal multicast networks, butnotmore. If I ask CNN abour RV live stream, and you ask the same, besure -the server send just 2 different packets - one for you and one forme...And this is very serious obstacle against multimedia services in theInternet. Not QoS (through QoS prevent using existing publicnetworksfrom the commercial telephony), but tjis absence of mukticasting intheInternet. On Mon, 17 May 1999, Steve Riley (MCS) wrote:Date: Mon, 17 May 1999 14:04:37 -0700 From: Steve Riley (MCS) <steriley () microsoft com> To: nanog () merit edu Subject: RE: Is anyone actually USING IP QoS? Nice to see that I'm not the only one believing in the foolishnessof QoShype. Bandwidth is essentially free, and will always be cheaperthan QoS.And since in the end nearly all decisions are based on economics,itshouldbe apparent which is the more logical decision. Allow me to point you to an interesting paper called "Rise of theStupidNetwork." Many of you here may have already seen this. It waswritten backin 1997 by David Isenberg, then a reasearcher at AT&T Labs(Isenberg isnowan independent consultant). His paper profoundly changed my viewson QoSandmade me realize that networks perform best when we limit how smarttheygetand ensure that networks focus on transport only. I urge everyoneto readit. Paper: http://www.rageboy.com/stupidnet.html Isenberg's site: http://www.isen.com/ _________________________________________________________ Steve Riley Microsoft Telecommunications Practice in Denver, Colorado email: mailto:steriley () microsoft com call: +1 303 521-4129 (cellular) page: +1 888 440-6249 or mailto:4406249 () skytel com Applying computer technology is simply finding the right wrench topoundinthe correct screw. -----Original Message----- From: Vadim Antonov [mailto:avg () kotovnik com] Sent: Monday, May 17, 1999 12:28 PM To: nanog () merit edu; pete () kruckenberg com Subject: Re: Is anyone actually USING IP QoS? Yep. Altough not _all_ QoS schemes are broken-as-designed. The most trivial per-packet priority combined with ingress priority mix shaping works. Ths idea of end-to-end whatever reservations or guarantees is usually propounded by people who either neglected their CS courses or those who are trying to sell it. Yep. The biggest QoS secret is that nobody actually needs it. Bandwidth is cheap and is growing cheaper. The manpower needed to deploy and maintain QoS is getting more and more expensive. --vadimAleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095)230-41-41,N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Current thread:
- RE: Is anyone actually USING IP QoS? Alex P. Rudnev (Jun 15)
- <Possible follow-ups>
- RE: Is anyone actually USING IP QoS? Alex P. Rudnev (Jun 15)
- Re: Is anyone actually USING IP QoS? Danny McPherson (Jun 15)
- Re: Is anyone actually USING IP QoS? Alex P. Rudnev (Jun 15)
- Re: Is anyone actually USING IP QoS? Vadim Antonov (Jun 15)
- Re: Is anyone actually USING IP QoS? Alex P. Rudnev (Jun 15)
- Re: Is anyone actually USING IP QoS? Brett_Watson (Jun 15)
- Re: Is anyone actually USING IP QoS? Alex P. Rudnev (Jun 15)
- Re: Is anyone actually USING IP QoS? Danny McPherson (Jun 15)
- Re: Is anyone actually USING IP QoS? Barry Dykes (Jun 15)
- Re: Is anyone actually USING IP QoS? Vadim Antonov (Jun 15)
- Re: Is anyone actually USING IP QoS? Vadim Antonov (Jun 15)
(Thread continues...)