RE: Is anyone actually USING IP QoS?

["Alex P. Rudnev" <alex () Relcom EU net>]

// 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 and enjoyed
> the discussion very much. It's NANOG so it isn't surprising there was little
> discussion of the edge of the networks.
>
> No one mentioned critical other functions for multicast and QoS: data
> distribution and interactive services. The growth in broadband is putting
> new services (and telephone is the simpliest) on the edge of the network.
> Data distribution is a model starburst is working on. I think the demand for
> it will grow exponentially. 
>
> As the broadband world grows there are real oportunities for interactive
> content placed near the edge of the network. This can not be centrally
> placed because of latency requirements for interactivity. The architecture
> requires 1000s of servers with pratically identical data on them. It's much
> like 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 way to do get
> the 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 mile will be
> more critical. Some of these apps require minimal latency or strict packet
> order. There is a strong future for QoS, but edge networks will require it
> much more than the Internet.
>
> I work for one of the new interactive companies. The lack of good tools and
> protocols 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-overbooked network. 
> It's not difficult to install PRECEDENCE queue-control, just as negotiate 
> about 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 you 
> abgour RV stream. Ok, you send packets with DST=MY_ADDRESS.
>
> Then someone else send second request. Why (WHY) can't RV server add 
> second 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 for multicast 
> multimedia, and add some mechanism (such as replicators) to hide the 
> mechanisms from the end user. No one bother if some RV-CACHE server catch 
> his request and use his own replicator to organise multidemia stream.
>
> Second way was choosen - to use another address space for the multimedia 
> multicasting. Result - you see - Internet have not (HAVE NOT) multimedia 
> multicast at all. No, some ISP have internal multicast networks, but not 
> more. If I ask CNN abour RV live stream, and you ask the same, be sure - 
> the server send just 2 different packets - one for you and one for me...
>
> And this is very serious obstacle against multimedia services in the 
> Internet. Not QoS (through QoS prevent using existing public networks 
> from the commercial telephony), but tjis absence of mukticasting in the 
> Internet.
>
>
>
> 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 foolishness of QoS
> > hype. Bandwidth is essentially free, and will always be cheaper than QoS.
> > And since in the end nearly all decisions are based on economics, it
> should
> > be apparent which is the more logical decision.
> >
> > Allow me to point you to an interesting paper called "Rise of the Stupid
> > Network." Many of you here may have already seen this. It was written back
> > in 1997 by David Isenberg, then a reasearcher at AT&T Labs (Isenberg is
> now
> > an independent consultant). His paper profoundly changed my views on QoS
> and
> > made me realize that networks perform best when we limit how smart they
> get
> > and ensure that networks focus on transport only. I urge everyone to read
> > it.
> >
> > 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 to pound
> in
> > the 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.
> >
> > --vadim
>
> 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)