Hi,
to answer the various question raised from the past 3 mails:
Markus,
Do I interpret your comments correctly in a sense that you consider
dynamic downloading of rules a requirement? If so, what timing do you
have in mind, i.e. how fast should a new rule be reflected in
corresponding OPES devices? Are you thinking in terms of seconds,
minutes hours? Maybe you could also give some examples that would
motivate such a requirement.
Given a call setup time typically ranges in seconds, I would say in seconds.
There might be a need to include more general "environmental"
conditions in the rule language, for example the bandwidth and/or load
issue you mentioned, but also things like time, date or general
timers. Maybe there's a place for rules like "if the local load on the
system is low, execute the service locally, otherwise do a remote
callout" or similar.
Yes, the load relief part is definitely one possible scenario.
Lee,
I'm a little unclear about what you're asking. Are you asking for the
ability to test the QOS policy as it applies to a given stream? For
example,
<property name="#QOS" matches="Gold|Silver">
where #QOS somehow maps to the QOS policy of the stream and then determine
the service class for that stream? (I've grossly simplified the QOS
policy
representation, of course, but I'm just trying to get a feel for the
request.
My first take on such a requirement is that it's more likely to be a
requirement for the adaptation service to be able to query the qos policy
than for the transit intermediary. But, of course, if that adaptation
service is remote it will need to have some value passed to it as a
parameter, yes? E.g.,
<action>callout://remote.service.com/adapter?qos=#QOS</action>
Yes, indeed the parameters can be embedded into the URI. Let me illustrates
what I am driving it with the following three scenarios:
(1) Adaptation of contents based on the QoS policy.
Examples includes adaptation of A/V streams based on bandwidth/jitter
requirements, adapting HTTP pages with images to a low bandwidth link
(perhaps large <IMG> replaced with ALT text equivalent).
For this case, the adaptation services do indeed need to be able to obtain
QoS parameters from the proxy.
The parameters can be embedded in the icap URI as parameters, like Lee
suggested. This would mean that (a) either the user must embed the clients'
bandwidth limitation in the HTTP headers when it send the request, or (b)
there must be someway for the rule engine to infer this based on the
client's ID (eg IP address) and dynamically construct the icap URI.
But, in the first place, what makes the rule engines think that the content
would need to be adpated? The client's allocated bandwidth may be more than
sufficient for the content. The easy way (without explicit support from
IRML) is to feed all contents to the adaptation service, and have the
adaptation service decide based on the given client QoS parameters.
Another way might be for IRML to give explicit support on this. For
instance, rules can be sepcified to check if adaptation is needed given the
client's allocated bandwidth.
As to which is the better approach, I will like to invite members on the
mailing list to discuss on. I personally is more inclined to seeing the
IRML with QoS support will be more efficient. (anyway, IMO, that is the
purpose of rule engines: to filter different contents to diufferent adpation
services)
(2) Real-time adaptation of contents.
Example includes adaptation of A/V streams based on current link status.
This is more applicable to wireless link, where the last hop channel
contition can fluctuate very rigourously. The distinction between this
scenario and the previous is that the actual available bandwidth may be less
than the requested bandwidth, and in order to gracefully maintain the
client's percieved QoS, adaptation of the contents should be carried out.
In this case, the adaptation service needs some way of obatining the network
condition from the the proxy. Then, a mechanism must be provided for the
rule engine to infer this from the network monitoring services in order to
dynamically construct the URI. That might be a consideration.
Similarly, for this case, do the rule engine simply forward every content to
the adaptation service (togetehr with link status information embedded in
the URI), or should the rule engine do filtering base on the current link
status of the client?
(3) QoS Policy control
In this scenario, suppose a client has a service policy of 64kbps bandwidth.
Suppose it has now a video stream with 56kbps, well within its bandwidth
range. Now suppose another stream of 16kbps audio arrives. The proxy can
perform a few things
(a) Discard the audio, (b) adapt the audio to the remaining bandwidth, (c)
adapt the video to give room for audio, (d) adapt both video and audio, etc.
IRML can be extended to perform such policy control (I am unclear if policy
control is in the charter of OPES, it seems so to me from the OPES website).
However, this will definitely requires IRML to have QoS extension.
Appreciates any comments.
thanks!
Chan Wah Ng