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

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 15:52:26 -0500

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 22 Oct 2015 14:05:08 -0700

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 <[email-masked]> wrote:

> 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.
>
> 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
> 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:
>
>
>    3. Both PT and RID are mandatory to implement; the offerer can elect
>    to use either.
> 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).
> 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.
>
> 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.
>
>
> 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.
>
> 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?
>
>
> ____
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 16:14:22 -0500

On 10/22/15 4:05 PM, Peter Thatcher wrote:
> 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. 

Yeah, so another nail in that coffin. Like I said in my earlier message, 
I don't think there's any sensible path that makes it mandatory, and 
that's even without bringing WebRTC into the analysis.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Oct 2015 12:49:38 -0400

> other "a=foo:bar" syntaxes out there, as described by this rule?

Yes please. And please follow the format for attribute definition 
established in rfc4566bis.

Also, I have some other issues:
- syntax allows two sends, or two recvs, but those are semantically 
forbidden
- the syntax allows paused with PTs, but that is semantically forbidden.
- syntax allows pt values that aren't numeric
- use of WSP (SP or HTAB). Contrary to typical SDP usage.

Below is a proposal for revised syntax that follows the spirit, but 
aligns better with other attributes and 4566bis. It doesn't have some of 
the extensibility of the prior syntax because I couldn't see how to do 
it in a meaningful way. I don't think it is a great loss here.

This may perhaps need further tweaking based on the ongoing discussion 
of pt vs rid.

The following would replace the beginning of section 6.1, or maybe be a 
new section/subsection. It also ought to be cross referenced from IANA 
considerations as a request to add it to the iana sdp attribute registry.

	Thanks,
	Paul

6.1 Simulcast attribute

    Name: simulcast

    Value: simulcast-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

       simulcast-value = sc-send-opt [SP sc-recv-opt]
                       / sc-recv-opt
       sc-send-opt = "send" SP sc-sendrecv-args
       sc-recv-opt = "recv" SP sc-sendrecv-args

       sc-sendrecv-args = sc-pt-args / sc-rid-args
       sc-pt-args = "pt=" sc-pt-list *(";" sc-pt-list)
       sc-rid-args = "rid=" sc-rid-list *(";" sc-rid-list)
                     [SP sc-pause-opt]

       sc-pt-list = payload-type *("," payload-type)
       sc-rid-list = rid-identifier *("," rid-identifier)
       sc-pause-opt = "paused=" sc-rid-list

       ; SP defined in [RFC5234]
       ; payload-type, defined in [draft-ietf-mmusic-rfc4566bis-15]
       ; rid-identifier defined in [I-D.pthatcher-mmusic-rid]

    Examples:

       a=simulcast: send pt=97;98 recv pt=97
       a=simulcast: send rid=1,2,3 recv rid=4 paused=3

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Oct 2015 10:22:16 -0700

>       simulcast-value = sc-send-opt [SP sc-recv-opt]

I like this, but I think that it can be improved further.

One annoying feature of your grammar is that this is valid:

a=simulcast:send rid=1 paused=2 recv pt=3

This makes it much harder to parse than ideal because you can't just
split on spaces, you have to process the paused as if it might also be
"recv".

It also permits rid and pt on the same line.

How about:

simulcast-value = simulcast-pt / simulcast-rid
simulcast-pt = ( simulcast-pt-send [ SP simulcast-pt-recv ] )
             / simulcast-pt-recv
simulcast-rid = ( simulcast-rid-send [ SP simulcast-rid-recv ] )
             / simulcast-rid-recv

simulcast-pt-send = "send" SP simulcast-pt-args
simulcast-pt-recv = "recv" SP simulcast-pt-args
simulcast-pt-args = simulcast-pt-list *(";" simulcast-pt-list)
simulcast-pt-list = payload-type *("," payload-type)

simulcast-rid-send = "send" SP simulcast-rid-args
simulcast-rid-recv = "recv" SP simulcast-rid-args
simulcast-rid-args = simulcast-rid-list *(";" simulcast-rid-list)
simulcast-rid-list = simulcast-rid-id *("," simulcast-rid-id)
simulcast-rid-id = [simulcast-rid-paused] rid-identifier
simulcast-rid-paused = "!"

Which would have paused streams prefixed with a character (I chose "!"
because it is the first character that is permitted by the SDP token
grammar but not the rid-identifier grammar, feel free to paint that
bikeshed any colour you like).

This:
      a=simulcast: send rid=1,2,3 recv rid=4 paused=3
Becomes:
      a=simulcast:send rid=1,2,3 recv rid=4,!4

And this is now invalid:
      a=simulcast:send pt=1 recv=rid=2

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Oct 2015 14:00:49 -0400

Martin,

Yeah, what you propose below is better.

But I'm not loving "!" - it is hard to distinguish from "1". Of course 
this isn't a problem for parsers, only for us humans reading examples 
and traces. I would prefer some other character, perhaps "-", "~" or "/".

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Oct 2015 11:10:15 -0700

On 23 October 2015 at 11:00, Paul Kyzivat <[email-masked]> wrote:
> But I'm not loving "!" - it is hard to distinguish from "1". Of course this
> isn't a problem for parsers, only for us humans reading examples and traces.
> I would prefer some other character, perhaps "-", "~" or "/".

As I said, I'm not partial to it.  It was selected on the basis that
it was the first valid choice.  I have no problem with "~" or "/",
though "-" is a valid rid identifier character.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 24 Oct 2015 08:32:16 -0700

> though "-" is a valid rid identifier character.

Alternative:

simulcast-rid-args = simulcast-rid-option *(";" simulcast-rid-option)
simulcast-rid-option = simulcast-rid-list [ "/" simulcast-rid-list ]
simulcast-rid-list = rid-identifier *("," rid-identifier)

Where everything after a slash is paused, e.g.,

a=simulcast:send rid=1,2,3/4,5;1,2/3,4,5

Noting that this makes the set of paused streams selectable.  The
original grammar did not.  I don't know if that makes sense.  If not,
then:

simulcast-rid-args = simulcast-rid-list *(";" simulcast-rid-list)
                               ["/" simulcast-rid-list]
simulcast-rid-list = rid-identifier *("," rid-identifier)

Which is simpler, e.g.,

a=simulcast:send rid=1,2,3;1,2/4,5

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Oct 2015 11:46:22 -0400

I'm like this less than the prior proposal. I find it less intuitive 
than decorating each id to indicate if paused. But we are probably bike 
shedding.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Sat, 24 Oct 2015 09:33:46 -0700

On 24 October 2015 at 08:46, Paul Kyzivat <[email-masked]> wrote:
> But we are probably bike shedding.

There is no "probably" about it. :)

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Oct 2015 18:07:00 +0000

Hi,

...

> - syntax allows two sends, or two recvs, but those are semantically forbidden

I believe use of WSP is forbidden in SDP.

> Below is a proposal for revised syntax that follows the spirit, but aligns better 
> with other attributes and 4566bis. It doesn't have some of the extensibility of 
> the prior syntax because I couldn't see how to do it in a meaningful way. I don't think it is a great loss here.
>
> ...
>
> 6.1 Simulcast attribute
>
>    Name: simulcast
>
>    Value: simulcast-value
>
>    Usage Level: media
>
>    Charset Dependent: no
>

I think it would also be good to indicate the multiplex group.

>       a=simulcast: send rid=1,2,3 recv rid=4 paused=3

Looks good.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Oct 2015 17:04:47 -0400

> I think it would also be good to indicate the multiplex group.

I'm not well informed on that. What should it say?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Oct 2015 22:21:41 +0000

Hi,

> I'm not well informed on that. What should it say?

Sorry, I meant "mux category" (https://tools.ietf.org/id/draft-ietf-mmusic-sdp-mux-attributes-10.txt).

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Oct 2015 16:32:59 -0700

> I believe use of WSP is forbidden in SDP.

I know that some parsers accept SP/HTAB.  Unfortunately, Firefox does
in a number of places.  But I've never seen any SDP grammar that
permits it.  We should definitely use SP.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Oct 2015 20:28:05 -0400

Martin pointed out a bug in the examples. Here is a correction:

6.1 Simulcast attribute

    Name: simulcast

    Value: simulcast-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

    Examples:

       a=simulcast:send pt=97;98 recv pt=97
       a=simulcast:send rid=1,2,3 recv rid=4 paused=3

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Oct 2015 23:45:00 -0400

> Sorry, I meant "mux category" (https://tools.ietf.org/id/draft-ietf-mmusic-sdp-mux-attributes-10.txt).

What category is it? Feel free to just tell me what the text should say.

	Thanks,
	Paul

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 25 Oct 2015 20:46:40 -0700

On Sun, Oct 25, 2015 at 8:45 PM, Paul Kyzivat <[email-masked]> wrote:

>> Sorry, I meant "mux category" (
>> https://tools.ietf.org/id/draft-ietf-mmusic-sdp-mux-attributes-10.txt).
>>
>

I think that RID is not affected my multiplexing and the category must be
NORMAL.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Oct 2015 14:16:30 +0000

Hi,

...

>I think that RID is not affected my multiplexing and the category must be NORMAL.

I agree that RID is probably NORMAL.

Regarding the ‘simulcast’ attribute, it would be nice to get some input from the simulcast folks.

If you have bundled multiple media, assuming it is ok to simulcast only parts of that media? If so, I guess the category would be NORMAL.

Regards,

Christer

---

From: Bo Burman <[email-masked]>
Date: Tue, 27 Oct 2015 18:30:28 +0000

Simulcast is defined to take bundle into account. It relies on the use of RID  or PT identification, but simulcast scope is per definition local to the surrounding “m=” line and simulcast extends the identification space by adding bundle MID identification in case of bundling. Therefore, it is not affected by multiplexing, meaning NORMAL.
/Bo

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: den 26 oktober 2015 14:17
To: Suhas Nandakumar; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] Open Issues: draft-ietf-mmusic-sdp-simulcast-03

Hi,

...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Oct 2015 15:17:44 -0400

On 10/27/15 2:30 PM, Bo Burman wrote:
> Simulcast is defined to take bundle into account. It relies on the use
> of RID  or PT identification, but simulcast scope is per definition
> local to the surrounding “m=” line and simulcast extends the
> identification space by adding bundle MID identification in case of
> bundling. Therefore, it is not affected by multiplexing, meaning NORMAL.

OK. Martin and I have provided you with some suggested text revisions 
regarding the syntax and registration of the attribute. While that text 
has most of the stuff needed for the IANA registration, it doesn't have 
info about multiplexing. If you incorporate the suggestion into the 
draft, you can put in the info about multiplexing.

	Thanks,
	Paul

> /Bo
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* den 26 oktober 2015 14:17
> *To:* Suhas Nandakumar; Paul Kyzivat
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] Open Issues: draft-ietf-mmusic-sdp-simulcast-03
>
> Hi,
>
> ...
>
> If you have bundled multiple media, assuming it is ok to simulcast only
> parts of that media? If so, I guess the category would be NORMAL.
>
> Regards,
>
> Christer
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 27 Oct 2015 15:43:08 -0700

On Tue, Oct 27, 2015 at 12:17 PM, Paul Kyzivat <[email-masked]>
wrote:

> regarding the syntax and registration of the attribute. While that text has
> most of the stuff needed for the IANA registration, it doesn't have info
> about multiplexing. If you incorporate the suggestion into the draft, you
> can put in the info about multiplexing.
>

[Suhas] .. I too think that both the RID and Simulcast draft needs to add a
statement assigning the Mux category as defined in
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-10#section-15
as IANA recommendation.

>> I think that RID is not affected my multiplexing and the category must
>>>
>> be NORMAL.
>>

---

From: Bo Burman <[email-masked]>
Date: Wed, 28 Oct 2015 12:28:23 +0000

OK. Thank you for the proposed syntax and registration text. Will bring it into -04. /Bo

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: den 27 oktober 2015 19:18
> To: Bo Burman; Christer Holmberg; Suhas Nandakumar
> Cc: [email-masked]
> OK. Martin and I have provided you with some suggested text revisions regarding the syntax and registration of the
> attribute. While that text has most of the stuff needed for the IANA registration, it doesn't have info about multiplexing.
> If you incorporate the suggestion into the draft, you can put in the info about multiplexing.
> 
> 	Thanks,
> 	Paul
> 
> > /Bo
> >
> > If you have bundled multiple media, assuming it is ok to simulcast
> > only parts of that media? If so, I guess the category would be NORMAL.
> >
> > Regards,
> >
> > Christer
> >