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

[Paul Kyzivat <[e-mail]>]

On 10/26/15 12:31 PM, Adam Roach wrote:
> 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.

This logic makes sense to me.

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

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

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

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.

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

This is a total non-starter.

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

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