[MMUSIC] Open Issues: draft-ietf-mmusic-sdp-simulcast-03

[Adam Roach <[e-mail]>]

I see no reason for us to all get in the same room to start hashing out 
the few open issues remaining on the simulcast draft. Going through my 
email and the draft itself, I see a only a very small handful of things 
that appear to be in need of a group decision. (I'm limiting myself to 
Simulcast in this email, and treating RID separately.)

If anyone -- and the draft authors in particular -- think we have more 
than these three open issues (one of which is a bikeshed color), please 
speak up quickly: once we're closed on all open issues, I think this 
draft is in reasonable shape to ask the chairs to WGLC.

The draft currently says:
>        Editor's note: The RID identification mechanism currently lacks a
>        declarative use definition.  As declarative use may also not
>        follow unified plan with a single media source per '"m="-line, it
>        is uncertain if declarative can be defined for the mechanism in
>        its current shape.

The motivation for RID stems from the fact that we can run out of PTs in 
offer/answer exchanges, since the offer necessarily needs to include a 
broad variety of options, which are typically whittled down to a tiny 
fraction of the offered PTs in an answer. In the declarative model, this 
dynamic isn't at play: the stream sender is simply announcing the nature 
of the streams it will send, and there's nothing the recipient of that 
declaration has to say on the matter. If I plan to send three simulcast 
streams, I'm going to use three PTs, rather than the multiplicative 
explosion that can result in offer/answer (without RID).

To that end, I would propose that we simply say RID-based simulcast is 
inapplicable in a declarative context, and that declarative uses of 
simulcast use PT only.

____

The draft currently says:
>     An offerer that is capable of using both simulcast stream
>     identification methods MAY include one "a=simulcast" line per
>     identification method in the offer.  Note that it is in general not
>     expected that the "pt" identification method will provide feature
>     parity with the "rid" method, and the different "a=simulcast" lines
>     can therefore express different use of simulcast functionality.
>     However, for some configurations the different identification methods
>     can be equivalent.
>
>     An answerer receiving an offer listing both simulcast stream
>     identification methods MUST choose only one and remove the other from
>     the answer.  An answerer not supporting a simulcast stream
>     identification method in the offer MUST remove the non-supported
>     "a=simulcast" line from the answer, possibly falling back to not
>     using simulcast at all.

This is clearly aimed at making one or both of the PT and RID 
identifications mechanisms optional. The document does not contain (as 
far as I've found) normative language requiring support of one or the 
other. Although there are other possible combinations, it seems that we 
have a small handful of superficially plausible approaches for 
offer/answer usage. I'm sure someone will point out if I've missed 
something sensible:

 1. PT is mandatory to implement, mandatory to include in offer. RID is
    optional to implement, and may be included alongside PT in an offer.
 2. RID is mandatory to implement, mandatory to include in offer. PT is
    optional to implement, and may be included alongside RID in an offer.
 3. Both PT and RID are mandatory to implement; the offerer can elect to
    use either.
 4. Neither PT nor RID are mandatory to implement. The offerer includes
    one or both, depending on what it supports.


#1 has the benefit of not requiring the extra machinery for the RID SDES 
and extension header for all implementations. This seems like a very 
mild advantage, given that it forces burning PTs on all possible 
simulcast variations, which pretty much defeats the reason for doing RID 
in the first place. Unless I'm mis-analyzing this, there's no way this 
could possible be viable.

#2 avoids all the shortcomings documented in section 8.2 of 
simulcast-03, and avoids the "PT exhaustion issue." The additional 
bandwidth described in section 8.3 should be negligibly small: on the 
order of 4 additional bytes on a small handful of packets at stream 
startup, and periodically throughout the stream (e.g., when I-frames are 
transmitted).

#3 avoids the PT exhaustion issue for #1, although it imposes the 
implementation complexity of both mechanisms on all implementations. 
Given that RID is significantly more flexible than PT, it's unclear why 
any implementation would choose to ever *send* PT in an offer under this 
model. Effectively, this resolves to a model of "everyone implements 
both but only ever uses RID." If that's where we're headed, let's just 
pull PT from the spec altogether.

#4 avoids the mandatory complexity described in #3, although it remains 
unclear why anyone would choose to implement only PT under this model 
(again, referring back to the limitations of using PT). You'll have some 
RID-only implementations, and some PT/RID implementations. In other 
words, if we write this down, the implementation reality will actually 
be #2. (And, if it isn't, then we'll have groups of mutually 
incompatible implementations, whenever a PT-only client meets a RID-only 
client).


I've heard it stated, in private conversations, that some parties wish 
to make PT mandatory to implement and RID optional to implement. That 
resolves to #1, which isn't workable (as I describe above). The only 
other option I can think of that is congruent with this statement would 
be making PT mandatory to implement, making RID optional to implement, 
and making both optional to include in an offer. In other words, you 
could have a RID-only offer, a PT-only offer, or an offer with both RID 
and PT. However, if the offer uses only RID, and the other end has not 
implemented the (optional-to-implement) RID mechanism, then you simply 
have a failure to interoperate.


Based on the foregoing, it seems that the only sensible recommendation 
(other than removing PT altogether) is something like #2. I know that's 
backwards from what some people have been expecting; as a concession to 
people how want things to work that way, I tried to come up with some 
option that could sensibly make PT mandatory and RID optional, but I 
just don't see it. If you see a flaw in my analysis, point it out.

____


BIKESHED TIME! I think Martin is correct that the "space-colon" 
delimiter is unaesthetic; I'll go further and point out that it appears 
to be unprecedented (I could be missing something), which will make it 
unnecessary parsing exception as compared to other attributes. Mo's 
point that we want a colon is well-taken, but that doesn't justify the 
space. It seems that the current formulation was selected to make the 
ABNF easy to write. To that end, I've put together a formulation for the 
"just a colon" format.

sc-attr     = "a=simulcast:" sc-str-list [WSP sc-str-list] [WSP sc-pause-list]


Is there any reason we can't make the format consistent with all the 
other "a=foo:bar" syntaxes out there, as described by this rule?


____

[minor nit for simulcast authors: in SDP examples, the "a=extmap" lines 
should use "urn:ietf:params:rtp-hdrext:sdes:rid" instead of 
"urn:ietf:params:rtp-hdrext:rid". I think the rid draft doesn't get this 
right in its examples either; I'll queue it up to be fixed in the next 
version.]

/a