Subject: [MMUSIC] MTI: PT, RID, Both, or Neither?

From: Adam Roach <[email-masked]>
Date: Mon, 26 Oct 2015 11:31:58 -0500

Clearly, I made a tactical error by including a rather serious issue in 
the same email as a bikeshed. Now that we have a giant drying mount of 
multicolor paint that has well and truly buried that poor bikeshed to 
the point of unrecognizability, I'd like to bring our attention back 
around to something of substantially more import.

I'll note that the subject of this email blithely gives four single-word 
options, but there's a lot of subtlety here. I've given it quite a bit 
of thought, and -- after a rather thorough analysis (which I summarize 
below) -- came to a conclusion that was completely unlike my original 
instinct on the topic. I would ask that you carefully read through the 
implications of each choice before responding.

That said, I *do* implore you to respond.

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.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Oct 2015 12:54:37 -0400

> could possible be viable.

This logic makes sense to me.

> startup, and periodically throughout the stream (e.g., when I-frames are

If you follow the logic here, then there is no reason to provide the 
mechanism to use PT.

> pull PT from the spec altogether.

Perhaps *somebody* will find the bandwidth saving worth doing.

But if the usage of PT is low, then the likelihood of it actually 
working will be slim.

> incompatible implementations, whenever a PT-only client meets a RID-only

This is a total non-starter.

> just don't see it. If you see a flaw in my analysis, point it out.

I think not really #2, but the variant where simulcast only provides the 
RID mechanism.

It should be really easy to paint over the PT part of the bikeshed. :-)

	Thanks,
	Paul

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 26 Oct 2015 22:37:43 -0700

As I stated in the previous thread where you asked the same question, I
think for use in WebRTC, only #2 and #4 are usable and #1 and #3 are not.

On Mon, Oct 26, 2015 at 9:31 AM, Adam Roach <[email-masked]> wrote:

> multicolor paint that has well and truly buried that poor bikeshed to the
> point of unrecognizability, I'd like to bring our attention back around to
> something of substantially more import.
>
> options, but there's a lot of subtlety here. I've given it quite a bit of
> thought, and -- after a rather thorough analysis (which I summarize below)
> -- came to a conclusion that was completely unlike my original instinct on
> the topic. I would ask that you carefully read through the implications of
> each choice before responding.
>
> 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.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Oct 2015 10:50:19 +0900

On 27 October 2015 at 01:31, Adam Roach <[email-masked]> wrote:
> 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.

I think that this is fine, though I could probably concede #4.  If I'm
correct, failure to negotiate here means that you don't get simulcast,
which is not necessarily the end of the world.  We could choose #4 in
this draft and have a stronger requirement in WebRTC (acknowledging
that logistical difficulties exist here).