[RTW] Constraint specifications (Re: Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements))

[Harald Alvestrand]

Wrapping up (?) on the "expressive power of constraint language" subthread:

My (tentative) conclusion is that we have uncovered a requirement that 
even when a correspondent chooses a codec / # streams combination that 
seems to be within the specification given by the other end, it should 
handle adequately the situation where the stream is refused from the 
other end - and, conversely, that the entity that accepts the stream 
needs to be able to say "no, I can't handle that at the moment, even 
though it's listed on my capabilities".

The number of (sometimes borderline) situations where it turns out that 
the system doesn't have the resources needed seems too large to express 
in a constraint language of finite complexity.

                  Harald


On 03/16/11 08:11, Christer Holmberg wrote:
> Hi,
>
>>>> My reason for drilling down so hard on this is that a
>>>> requirement to express set difference complicates a negotiation language
>>>> by a rather large amount compared to just doing set intersection.
>>> (The problem is most acute when dealing with ACLs, where adding set
>>> difference usually makes it impossible for an administrator
>>> to figure out what exactly he's specified for any rule set of some
>>> complexity, but it's a problem for any such language.)
>>>
>> So, I've been assuming that this group would end up with
>> something similar to CONNEG-style set intersection, in part
>> because that the choice we saw in SIP.  In RFC 2533
>> semantics, this sort of grouping of permitted features into
>> feature sets is certainly possible.  I believe it would
>> handle the issue of related features reasonably well (e.g.
>> Video codec FOO can be used with audio codec BAR or BAZ, but
>> not GOO; video codec HOO can be used audio codec BAR or GOO,
>> but not BAZ).
>>
>> But it won't be simple if the issue is actually one of
>> overall system constraints.  If the first stream consuming X
>> amount of resources by negotiating video codec FOO with audio
>> codec BAZ means that second one can only have FOO if it will
>> take BAR, the situation will get ugly fast.  In general,
>> CONNEG style negotiation relies on the ability of an end
>> system to express its constraints well, and shifting
>> constraints are hard to deal with.  Functionally, you'd have
>> to restart the negotiation completely after each stream
>> started to consumer resources; that's going to make
>> server-based negotiation pretty hard.
>>
>> It seems to me it would be far better to add a "number of streams"
>> parameter to the API requesting the supported codecs, so that
>> the host system/browser can determine what it can support for
>> that number of streams.  It may still express feature sets,
>> but it should eliminate those which it could not support over
>> the full set of streams on resource grounds. This has some
>> suboptimal cases, but the overall approach seems to me more
>> likely to complete the negotiation in a reasonable time with
>> acceptable results.
> That can be done, but we need to remember that different types of streams can consume different amount of resources.
>
> Take video conference as an example: the stream for the main display (e.g. representing the active speaker) might use a very resource consuming codec/format/resolution, while there can be a number of streams for small "thumbnail" displays that require much less resources.
>
> We also need to ensure that we don't make life to difficult for the web app developer, by mandating him/her to browse through a potentially large list of alternatives before requesting streams.
>
> So, I agree that being able to query for different alternatives is a good thing, but it should also be possible for the web app to simply request an explicit stream set (based on web app logic and/or an offer received from the remote peer), which is then either accepted or rejected by the browser. And, if rejected, it would then be good if the browser provided some information on why it was rejected. The web app could then either query for alternatives, OR simply try to request a new stream set (based on the error information provided by the browser for the previous request).
>
> Regards,
>
> Christer
>