Subject: Genart Telechat review: draft-ietf-avtext-rtp-grouping-taxonomy-07

From: Robert Sparks <[email-masked]>
Date: Mon, 06 Jul 2015 15:41:01 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avtext-rtp-grouping-taxonomy-07
Reviewer: Robert Sparks
Review Date: 6 Jul 2015
IETF LC End Date: past
IESG Telechat date: 9 Jul 2015

Summary: Ready for publication as an Informational RFC

Thanks for addressing the comments I made at LC.

Very small nit:

I still worry that with "at least some content ... at some point during 
its lifetime" that you are improperly excluding streams that may never 
send RTP packets (because of silence suppression or the way a codec 
works), when RTCP will be sent. This could happen in a multimedia 
situation where multiple microphones are signaled, but one just happens 
to never get used for example.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 07 Jul 2015 13:34:01 -0500

On 7/7/15 12:22 PM, Bo Burman wrote:
>
> Regarding your remaining nit:
>
> Am I interpreting you correctly that you are concerned with RTP 
> streams that only sends RTCP, never anything else?
>
Yes.
>
> We have two concepts in the draft that are affected by this; Source 
> RTP Streams and Redundancy RTP Streams. If no RTP data is ever sent, 
> how do we distinguish between an “empty” Source RTP Stream and an 
> “empty” Redundancy RTP Stream?
>
I'm not sure why you would need to. Maybe that's why I don't understand 
why you need the qualification in the first place?
>
> Would it be enough with a formulation saying that _/if/_ any RTP data 
> is ever sent, a Source RTP Stream would take that from an Encoded 
> Stream? Would that take care of your concern?
>
Probably.

Think of it this way - look at Figure 1 in the current draft.
Consider an encoder that does silence suppression as a special case of 
VBR encoding, and the case I mention where silence suppression is 
constantly on, and the resulting bit rate is zero. Now, after encoding, 
and packetizing, you hit the new RTP-based Security boxes, which are 
configured through some magic to combat the known security issues with 
using VBR encodings by producing a constant rate output. You still want 
to talk about source streams in this case even if they're empty  - while 
there aren't packets going into that security box, there are lots of 
packets coming out.

RjS
>
> *From:*Robert Sparks [mailto:[email-masked]]
> *Sent:* den 6 juli 2015 22:41
> *To:* General Area Review Team; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Genart Telechat review: 
> draft-ietf-avtext-rtp-grouping-taxonomy-07
>
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> I still worry that with "at least some content ... at some point 
> during its lifetime" that you are improperly excluding streams that 
> may never send RTP packets (because of silence suppression or the way 
> a codec works), when RTCP will be sent. This could happen in a 
> multimedia situation where multiple microphones are signaled, but one 
> just happens to never get used for example.
>

---

From: Bo Burman <[email-masked]>
Date: Tue, 7 Jul 2015 17:22:46 +0000

Regarding your remaining nit:
Am I interpreting you correctly that you are concerned with RTP streams that only sends RTCP, never anything else?
We have two concepts in the draft that are affected by this; Source RTP Streams and Redundancy RTP Streams. If no RTP data is ever sent, how do we distinguish between an “empty” Source RTP Stream and an “empty” Redundancy RTP Stream? Would it be enough with a formulation saying that _if_ any RTP data is ever sent, a Source RTP Stream would take that from an Encoded Stream? Would that take care of your concern?

From: Robert Sparks [mailto:[email-masked]]
Sent: den 6 juli 2015 22:41
To: General Area Review Team; [email-masked]; [email-masked]; [email-masked]
Subject: Genart Telechat review: draft-ietf-avtext-rtp-grouping-taxonomy-07

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Very small nit:

I still worry that with "at least some content ... at some point during its lifetime" that you are improperly excluding streams that may never send RTP packets (because of silence suppression or the way a codec works), when RTCP will be sent. This could happen in a multimedia situation where multiple microphones are signaled, but one just happens to never get used for example.

---

From: Bo Burman <[email-masked]>
Date: Wed, 8 Jul 2015 08:38:46 +0000

Thanks Robert, I get your point and I think it is valid.

From: Robert Sparks [mailto:[email-masked]]
Sent: den 7 juli 2015 20:34
To: Bo Burman; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Genart Telechat review: draft-ietf-avtext-rtp-grouping-taxonomy-07

We have two concepts in the draft that are affected by this; Source RTP Streams and Redundancy RTP Streams. If no RTP data is ever sent, how do we distinguish between an “empty” Source RTP Stream and an “empty” Redundancy RTP Stream?
I'm not sure why you would need to. Maybe that's why I don't understand why you need the qualification in the first place?
[BoB] In practice, you clearly don’t, but this is about naming. It should be possible to avoid confusion with some careful wording (see below).

Would it be enough with a formulation saying that _if_ any RTP data is ever sent, a Source RTP Stream would take that from an Encoded Stream? Would that take care of your concern?
Probably.

Think of it this way - look at Figure 1 in the current draft.
Consider an encoder that does silence suppression as a special case of VBR encoding, and the case I mention where silence suppression is constantly on, and the resulting bit rate is zero. Now, after encoding, and packetizing, you hit the new RTP-based Security boxes, which are configured through some magic to combat the known security issues with using VBR encodings by producing a constant rate output. You still want to talk about source streams in this case even if they're empty  - while there aren't packets going into that security box, there are lots of packets coming out.
[BoB] OK. I agree that a slight re-formulation is needed where the requirement to send data in the Encoded Stream is removed. Please notify me when it is appropriate to issue another revision of the document.

RjS

From: Robert Sparks [mailto:[email-masked]]
Sent: den 6 juli 2015 22:41
To: General Area Review Team; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Genart Telechat review: draft-ietf-avtext-rtp-grouping-taxonomy-07

Very small nit:

---

From: Jari Arkko <[email-masked]>
Date: Thu, 9 Jul 2015 00:17:24 +0200

Bo, Robert - thank you very much for the review and considering the review comments.

Jari