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

[Ted Hardie]

On Mon, Mar 14, 2011 at 11:42 PM, Harald Alvestrand
<harald at alvestrand.no> wrote:

> 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.

regards,

Ted Hardie