RE: Is anyone actually USING IP QoS?

Mailman List Mirror (Read Only)
1

Alex Rudnev wrote:

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.

Actually, it makes sense to do per-packet drop priority as opposed to
precedence priority; in this case edge routers can arbitrarily
tweak packet priorities w/o worrying about packet reordering in the network.

I'd like to ask one more question. Multicast,

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.

Because IP multicasts are broken as designed?

Actually, there are two multicasting approaches which use unicast address
space to identify the multicasting channel: the Express multicast by
David Cheriton & Co (Stanford U) and my earlier TRAP proposal. Both
are significantly more scalable than the existing IP mcast; and the
TRAP one has a property of not keeping any state in gateways which
do not perform any packet replication.

In any case, L3 mcasting seems to be pretty much dead. Replicating
canned content is better done with caches, and conferencing requiries
real MCUs which do things like speaker selection and noise suppression.

Injection of end user-supplied routing information (JOIN/LEAVE requests)
into the core backbones is not going to work in a real life, period.

--vadim

2

Because IP multicasts are broken as designed?

And because (I guess) Internet lost such thing as, I do not know exact
name, fixed addresses for the fixed services: for example, 254.0.0.1 for
DNS, 254.0.0.2 for mail relay, etc etc. First IP drafts seems to had such
ideas, but then this ideas was lost, and that make media caching more
difficult (through possible) task to realise.

In any case, L3 mcasting seems to be pretty much dead. Replicating

I better prefer to say _it's the train which is over already_. Existing
network have a much of multimedia sources, and they don't use multicast.
Now there is easy to add caching and autho-replication then to build
parallel multicast network based on very complex and suspicious
mechanisms. Through, multicast can feel itself well - in the end LANs.

Alex. /sitting 10 meters next to the workstation where multicast is
used for internet TV experiments/.

canned content is better done with caches, and conferencing requiries
real MCUs which do things like speaker selection and noise suppression.

Injection of end user-supplied routing information (JOIN/LEAVE requests)
into the core backbones is not going to work in a real life, period.

--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)