Subject: Re: [avtext] Spencer Dawkins' No Objection on draft-ietf-avtext-rid-08: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Thu, 6 Oct 2016 14:05:53 -0500

Sorry for the delay in responding here.

On 8/29/16 16:03, Spencer Dawkins wrote:
> In this text from the Introduction,
>
>     RTP sessions frequently consist of multiple streams,
>     
> would it be possible to add a word or two explaining why this happens? If
> it's true that this happens because multiple media types, or codecs, or
> ... are in use in the same RTP session, that's the level of detail I'm
> thinking about.

The most relevant reasons for what we're working on here are simulcast, 
layered encodings, and redundancy streams, all of which are mentioned in 
the introduction already. With that in mind, it's not clear to me what 
you're asking to have added.

> In this text:
>
>     At the same time, when redundancy RTP streams are in use,
>     
> could you provide a reference for redundancy RTP streams? I'm guessing
> this is using RFC 7198, but that's just a guess.

The Terminology section calls out :

..."redundancy RTP stream" are used as defined in {{RFC7656}}.

Is that sufficient, or do you want additional text?

> I was impressed that you included this,
>
>     These
>     redundant RTP streams may also contain their own unique RtpStreamId.
>     
> but (of course) started wondering why you'd do that - can the RtpStreamId
> for a redundancy RTP stream appear as a RepairedRtpStreamId for a third
> RTP stream? Or is there some other reason to assign an RtpStreamId?

This design is the result of a couple of countervailing forces on the 
mechanism. One sought to have a single ID per "thing that is rendered to 
the user," which would be a source RTP stream, including all of its 
redundancy streams. This design was driven in large part by the API 
exposed to web applications via the WebRTC APIs. Another school of 
thought sought to have a unique ID per RTP stream [1], so that future 
SDP mechanisms would have the ability to refer to RTP streams at the 
smallest level of granularity possible, should they need to. The current 
design, with two kinds of identifiers, is the result of some rather 
careful consensus building to satisfy both camps: redundancy 
relationships can be signaled as part of the RTP (allowing the API to 
refer to the whole cohort with a single ID), while redundancy streams 
can be uniquely referred to by future extensions.

/a

___
[1] The terminology here isn't awesome, but at least it's precise -- you 
just need RFC7656 to untangle it

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Oct 2016 15:55:15 -0500

Hi, Adam,

On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach <[email-masked]> wrote:

> the introduction already.

That's true.

> With that in mind, it's not clear to me what you're asking to have added.

I was thinking of one level up from the specific reasons that are sprinkled
around later in the introduction. I was guessing at some of the reasons
("multiple media types, or multiple codecs, or ...").

If there's no limit to the reasons why an RTP session needed more than one
stream, it may not be possible to explain that at a higher level. And if
there's no limit, that wouldn't surprise me a bit.

> Is that sufficient, or do you want additional text?

I was asking for a reference on first use, which is in the Introduction.
The alternative is that people would need to keep reading until they get to
the reference in the Terminology section. Do the right thing :-)

> redundancy streams. This design was driven in large part by the API exposed
> to web applications via the WebRTC APIs. Another school of thought sought
> to have a unique ID per RTP stream [1], so that future SDP mechanisms would
> have the ability to refer to RTP streams at the smallest level of
> granularity possible, should they need to. The current design, with two
> kinds of identifiers, is the result of some rather careful consensus
> building to satisfy both camps: redundancy relationships can be signaled as
> part of the RTP (allowing the API to refer to the whole cohort with a
> single ID), while redundancy streams can be uniquely referred to by future
> extensions.

This is helpful background, thanks.

I was asking a more limited question. If someone has

RtpStreamId A repaired by RtpStreamId B
RtpStreamId B repaired by RtpStreamId C

should an implementation be surprised? That's what wasn't clear to me from
the text.

> just need RFC7656 to untangle it

Indeed! I was present for some of the discussions that made it obvious that
RFC was needed, but moved from RAI to TSV when work started on it. Thanks
for the pointer. :-)

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Oct 2016 16:18:24 -0500

On 10/6/16 15:55, Spencer Dawkins at IETF wrote:
> Hi, Adam,
>
> On Thu, Oct 6, 2016 at 2:05 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The most relevant reasons for what we're working on here are
>     simulcast, layered encodings, and redundancy streams, all of which
>     are mentioned in the introduction already. 
>
>
> That's true.
>
> I was thinking of one level up from the specific reasons that are 
> sprinkled around later in the introduction. I was guessing at some of 
> the reasons ("multiple media types, or multiple codecs, or ...").
>
> If there's no limit to the reasons why an RTP session needed more than 
> one stream, it may not be possible to explain that at a higher level. 
> And if there's no limit, that wouldn't surprise me a bit.

Yeah, there's really no limit. RFC 3550, section 5.2, basically says 
"any time these conditions don't apply to you, you can multiplex several 
streams on a single session." It's done a lot, and new reasons seem to 
come up with some regularity. The reasons for doing so vary pretty 
widely, and include things like correlation, fate sharing, and reducing 
the number of ports consumed (both on hosts and on NATs). I think that a 
treatment of the reasons multiplexing happens would be either way too 
large for the introduction -- overwhelming the discussion of the actual 
RID mechanism -- or so poorly covered as to do readers a disservice.

> I was asking for a reference on first use, which is in the 
> Introduction. The alternative is that people would need to keep 
> reading until they get to the reference in the Terminology section. Do 
> the right thing :-)

So you want it to read something like "At the same time, when redundancy 
RTP streams (see [RFC7656]) are in use, we also..." Is that right?

>     This design is the result of a couple of countervailing forces on
>     the mechanism. One sought to have a single ID per "thing that is
>     rendered to the user," which would be a source RTP stream,
>     including all of its redundancy streams. This design was driven in
>     large part by the API exposed to web applications via the WebRTC
>     APIs. Another school of thought sought to have a unique ID per RTP
>     stream [1], so that future SDP mechanisms would have the ability
>     to refer to RTP streams at the smallest level of granularity
>     possible, should they need to. The current design, with two kinds
>     of identifiers, is the result of some rather careful consensus
>     building to satisfy both camps: redundancy relationships can be
>     signaled as part of the RTP (allowing the API to refer to the
>     whole cohort with a single ID), while redundancy streams can be
>     uniquely referred to by future extensions.
>
>
> should an implementation be surprised? That's what wasn't clear to me 
> from the text.

I think that depends entirely on the repair mechanism. It doesn't make 
sense with any that are currently defined, but I don't think anything 
precludes it from happening in the future. I could be wrong on either count.

/a

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Oct 2016 16:27:59 -0500

Hi, Adam,

On Thu, Oct 6, 2016 at 4:18 PM, Adam Roach <[email-masked]> wrote:

> sprinkled around later in the introduction. I was guessing at some of the
> reasons ("multiple media types, or multiple codecs, or ...").
>
> Yeah, there's really no limit. RFC 3550, section 5.2, basically says "any
> time these conditions don't apply to you, you can multiplex several streams
> on a single session." It's done a lot, and new reasons seem to come up with
> some regularity. The reasons for doing so vary pretty widely, and include
> things like correlation, fate sharing, and reducing the number of ports
> consumed (both on hosts and on NATs). I think that a treatment of the
> reasons multiplexing happens would be either way too large for the
> introduction -- overwhelming the discussion of the actual RID mechanism --
> or so poorly covered as to do readers a disservice.
>

Thanks for helping me understand your thinking. I agree with you. If you DO
happen to see a pony, I'd like one, but ...

> RTP streams (see [RFC7656]) are in use, we also..." Is that right?

That's what I was thinking. I found myself guessing what was being referred
to, and the reference on first use would have helped me do the right thing.

> precludes it from happening in the future. I could be wrong on either count.

Ah, I see your problem. You can't say whether that makes sense *in this
spec*. That makes perfect sense to me. I wonder if it's worth saying that,
but you're doing pretty well at doing the right thing, so I'm sure you will
here, too.

And thanks for your help.

Spencer

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Oct 2016 17:28:12 -0500

On 10/6/16 16:27, Spencer Dawkins at IETF wrote:
> Ah, I see your problem. You can't say whether that makes sense *in 
> this spec*. That makes perfect sense to me. I wonder if it's worth 
> saying that, but you're doing pretty well at doing the right thing, so 
> I'm sure you will here, too.

I've kind of turned this over in my mind a few times, and I'm afraid 
that anything I could say here would make things more confusing. As far 
as I can tell, the prospect that the repair stream structure you 
describe might arise is kind of remote; and, if it does arise, I think 
it'll be clear enough to the authors of any such mechanism to describe 
how it works with RID. For the time being, because it's just such an 
esoteric sounding kind of thing, I suspect that trying to describe it 
will confuse more people than it helps.

Which is to say: unless you feel strongly that a change is needed here, 
I think the document is ready to ship.

/a

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 18 Oct 2016 21:57:10 -0500

Adam,

>
>
>
> I've kind of turned this over in my mind a few times, and I'm afraid that
anything I could say here would make things more confusing. As far as I can
tell, the prospect that the repair stream structure you describe might
arise is kind of remote; and, if it does arise, I think it'll be clear
enough to the authors of any such mechanism to describe how it works with
RID. For the time being, because it's just such an esoteric sounding kind
of thing, I suspect that trying to describe it will confuse more people
than it helps.
>
> Which is to say: unless you feel strongly that a change is needed here, I
think the document is ready to ship.

I don't feel strongly that a change is needed. I was pushing on what looked
like a corner case, and it is one, but it's not one you can nail down *in
this spec*.

So I agree with you that the spec is ready to ship without text changes to
address my comment.

I really appreciate you educating me on how this fits together, as well as
considering my comments.

Tell the RFC editor I said "hi" ;-)

Spencer