ubiQoS Active Path Determination (...follows)

A request is forwarded if and only if:

the client request can be still satisfied, signaled by a still positive cost value;
the proxy examining the request is not already included in the list of traversed ones, to avoid loops;
the number of traversed proxies is less than a configurable maximum number of hops.

Once reached a potentially suitable server, proxies start exchanging a new sequence of coordination messages on the way back of the determined path, this time going backwards from the server to the client. Any proxy performs the needed local resource reservation and possibly decides if a downscale tailoring operation should operate in its locality. The enforced policy is to downscale the flow at the first possible node in the server-to-client path, according to the QoS requirements of all served clients in the distribution sub-tree. In addition, any proxy determines the actual costs associated with its active path segment. These costs could be different from the ones determined in the client-to-server way, e.g., because of the tailoring decisions made on the way back.

At the end, the client stub receives all service bids together with their associated costs to let the user choose among them. The user choice triggers the VoD flow starting on the dynamically determined QoS-aware path. The client stub ignores any other service bid received after the choice. In addition, the intermediate nodes belonging to alternative active paths, not chosen for final service provisioning, invalidate their reservations after a configurable timeout and release the corresponding local resources.

Let us finally observe that proxies can not only behave as clients when forwarding requests towards the VoD servers, but also act as servers when a received request can be satis-fied by either a currently traversing VoD content or a locally cached one. This produces the dynamic determination of active multicast distribution trees. To have further details about ubiQoS multicast, please follow the link...