RE: Is anyone actually USING IP QoS?
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
Because IP multicasts are broken as designed?
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
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. 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)
participants (2)
-
Alex P. Rudnev -
Vadim Antonov