|
|
|
ubiQoS Active Path Determination
The determination of active paths is achieved dynamically by ubiQoS proxies,
which organize a network of P2P mediators. ubiQoS proxies solve
the QoS routing problem by collaborating in building suitable QoS-aware paths
in response to client requests.
Any ubiQoS locality
hosts at least one proxy. If multiple proxies are available in
the same locality, only one of them has registered in the local discovery
service as the primary mediator. The other proxies register themselves as
secondary mediators, capable of replacing the primary for fault-tolerance reasons,
similarly to what occurs for DNS fault tolerance. Anytime either a ubiQoS client
stub is likely to request a VoD flow or a ubiQoS server stub is likely to update
the lists of offered VoD contents, they communicate their willingness to the
primary proxy in their locality. At their first interaction, stubs interrogate
the local discovery service to obtain the complete list of the
proxies available in the locality. Successively, they re-interrogate discovery
only in case of failure of both the primary proxy and all already known
possible secondary ones.
On the one hand, a server
with a newly offered VoD content sends an XML-based advertisement to its
local ubiQoS proxy by specifying a title for the VoD flow, its textual
de-scription, a tuple indicating the maximum QoS level offered (in the current
implementation, expressed only in terms of frame size and frame rate), and the
associated cost as a poly-nomial function of the QoS parameters
included in the tuple. ubiQoS proxies automatically invalidate VoD content
entries from servers at regular time intervals; server
stubs are in charge of refreshing registrations by renewing the lease
if they are interested to continue to offer the registered VoD flows.
On the other hand, a
client requesting a VoD flow interrogates the proxy with an XML-based
query that can include a search sub-string for the VoD title,
a search sub-string for the VoD description, a tuple with the
minimum acceptable values for QoS parameters, the maximum
price the client is ready to pay for the service, and an initially void
list of prox-ies already traversed by the query (the partially determined candidate
for the active path).
When a ubiQoS proxy receives a query from one client stub, it first checks in its registration table to find a directly known server stub that provides a compatible VoD content. If several are found, the minimum cost server is chosen. Otherwise, the proxy acts as a client in the P2P mediator network and forwards the request to maximum N proxies (N is con-figurable and usually put to 5) in close ubiQoS localities. Close proxies are reached by exploiting the SOMA naming system and the SOMA locality organization. Before any request forwarding, the proxy decrements the maximum cost specified by the client by the cost associated to the transmission of the VoD content with the minimum acceptable QoS level over the link client-to-proxy. In addition, it includes its GUID to the list of traversed proxies in the query.
