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