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

[Peter Thatcher <[e-mail]>]

To me, making PT-based simulcast mandatory is not an option compatible with
WebRTC 1.0.  If we make it mandatory, then we make these drafts unusable
for WebRTC 1.0.   If we're rushing to get this work done for WebRTC 1.0, we
might as well make it usable for it, which means making PT-based simulcast
optional.

In other words, I'm fine with #2 or #4, but not #1 or #3.



On Thu, Oct 22, 2015 at 1:52 PM, Adam Roach <[e-mail]> wrote:

> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>