Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 14 Nov 2014 17:31:47 +0000

(As WG cochair) 

This is to start a working group last call on draft-ietf-avtext-rtp-grouping-taxonomy-03.

To cater for the end of the IETF meeting, and for various national holidays, this working group last call will last three weeks.

Therefore please comment on this document by Friday 5th December 2014.

Please send comments to the working group list.

It is helpful to give some assessment of the nature of your comment, as to whether you regard it as editorial, minor technical, or a rather more major flaw.

Regards

Keith

-----Original Message-----
From: avtext [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 November 2014 12:05
To: [email-masked]
Cc: [email-masked]
Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF.

        Title           : A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
        Authors         : Jonathan Lennox
                          Kevin Gross
                          Suhas Nandakumar
                          Gonzalo Salgueiro
                          Bo Burman
	Filename        : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
	Pages           : 42
	Date            : 2014-11-14

Abstract:
   The terminology about, and associations among, Real-Time Transport
   Protocol (RTP) sources can be complex and somewhat opaque.  This
   document describes a number of existing and proposed relationships
   among RTP sources, and attempts to define common terminology for
   discussing protocol entities and their relationships.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-03

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 15 Nov 2014 21:56:30 +0000

Hi,
I read through this draft once more, and have a few remaining comments (a
few others were previously communicated to Bo in private and are
adequately addressed).

1. Section 2.1.2, Characteristics.
Suggest to add a characteristic: ³The nature of the media capture may
impose constraints on the clock handling in some of the future steps.  For
example, many audio Video Capture devices are not completely free in
selecting the sample rate.²

2. Section 2.1.4, mixing
I think the language at the top of page 9 is a bit misleading.  In many
(most? all?) video related cases, the ³selection² is dealt with in the
coded or compressed domain; that is, what is being switched are Encoded
Streams and not Raw Streams.  In the remaining video cases, one certainly
cannot disregard timing here (see below).
I¹m also not sure that in an audio mixer it would be ³Raw Streams² that
are being mixed.  Certainly, a useful audio mixer is timing-aware, and in
that case it would mix multiple Source Streams into a resulting Source
Stream, rather than multiple Raw Streams into a resulting Source Stream.

3. Section 2.1.10, use of ³redundancy"
Many media coding formats allow to include redundancy--be it in the form
of in-media FEC like what is available in opus and ITU video codecs, or
source-coding based error resilience redundancy (like intra macro blocks
in any modern video video coding).  Perhaps it could be made clearer that
³without additional redundancy² explicitly excludes these techniques--in
other words, the term redundancy here refers exclusively to redundancy
added through FEC, duplication, re-transmission and similar RTP-based
tools.  Perhaps best would be to make it clear that most suitable Media
Encoders add some redundancy into Encoded Streams to make them cope better
with inevitable losses of RTP, but that there are in addition ways
(discussed later) to add further redundancy protecting the RTP stream
itself (rather than the Encoded Stream).

4. Section 2.1.11, ³Media Redundancy²
For anyone who worked on joint source-channel coding and optimization, the
term ³Media Redundancy² is not intuitive here; in fact, many would
consider it plainly inappropriate.  The redundancy introduced in this
section is added on the transport and generally protects transport units,
namely sequences of RTP packets (that it also happens to protect the
Encoded Stream carried in the RTP Stream² is a wanted side effect.)
I had a short discussion about that term with Bo.  He said that a lot of
mobile folks would find ³Transport Redundancy² also incomplete, as many
folks would associate such term with radio layer stuff.  Perhaps
³RTP-based Redundancy²?

5. 2.1.18, result of a failed checksum test
Bo and I had a discussion about that as well, and I¹m happy to see that
the harsh language of previous drafts is gone (in previous drafts, packets
that fail checksum tests are dropped, period--ignoring things like
UDP-lite).  Perhaps it may be worth mentioning that sensible system
designs either drop packets, or flag the questionable packets in the
resulting Received RTP Stream somehow so to alarm a Media Decoder about
the possible corrupt state.  (That said, the media decoder needs to be
error tolerant anyway, as in bit error prone networks the chance of a
packet with passed UDP checksum still including bit errors is quite high.

6. 2.1.21 ³Media Repair²
This section title has a similar problem as ³Media Redundancy.  Most joint
source-channel coding folks would associate with the term ³media repair²
things like error concealment, interpolation, ...) and not the application
of FEC that is being sent outside of the Encoded Stream.  So different
terminology is needed, and it should be aligned with the outcome of the
³Media Redundancy² discussion.  Further, what really is repaired here is
the received RTP Stream itself and not the Received Source Stream; at
least not directly.  So I guess, the right way to express this would be as
follows:  RTP Stream Repair is the Transformation that takes as input one
or more received Source RRP Streams and received Redundancy RTP Streams,
and produces one or more Received RTP Streams that are as close to the
sent Source RTP Streams as possible (utilizing FEC repair, retransmission,
whatever).²

7. 2.2.1 End Point and editor¹s note
Remove the note, and pick one (soon).

8. Section 3, header
change section title to ³Concepts of Inter-Relations² (add the ³of²)
Overall, I find this section (not its subsections) overly abstract and
also hard to read, but have no suggestions to improve it.

Regards,
Stephan

On 11/14/14, 7:31, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

>(As WG cochair) 
>
>This is to start a working group last call on
>draft-ietf-avtext-rtp-grouping-taxonomy-03.
>
>To cater for the end of the IETF meeting, and for various national
>holidays, this working group last call will last three weeks.
>
>It is helpful to give some assessment of the nature of your comment, as
>to whether you regard it as editorial, minor technical, or a rather more
>major flaw.
>
>Regards
>
>Keith
>
>Subject: [avtext] I-D Action:
>draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
>
>
>        Title           : A Taxonomy of Grouping Semantics and Mechanisms
>for Real-Time Transport Protocol (RTP) Sources
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 18 Nov 2014 17:06:11 +0000

One more…
9. Section 3.5 defines the three new categories for layered transmission
(MRST, MRMT, and SRST, as [... On a [single/multiple] "Transport[s]".
That should me “Media Transport[s]”.
Thanks,
Stephan

On 11/15/14, 13:56, "Stephan Wenger" <[email-masked]> wrote:

>>http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-
>>0
>>3
>>
>>

---

From: Bo Burman <[email-masked]>
Date: Thu, 27 Nov 2014 14:27:47 +0000

Stephan, 

Thank you for your review and a set of very good comments! Please find my answers inline below.

Cheers,
Bo

> From: avtext [mailto:[email-masked]] On Behalf Of Stephan Wenger
> Sent: den 15 november 2014 22:57
> To: [email-masked]
> Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt
> 
> Hi,
> I read through this draft once more, and have a few remaining comments (a few others were previously communicated
> to Bo in private and are adequately addressed).
> 
> Suggest to add a characteristic: ³The nature of the media capture may impose constraints on the clock handling in some
> of the future steps.  For example, many audio Video Capture devices are not completely free in selecting the sample
> rate.²
[BoB] Makes a lot of sense. Will add that in next version.

> 
> 2. Section 2.1.4, mixing
> I think the language at the top of page 9 is a bit misleading.  In many (most? all?) video related cases, the ³selection² is
> dealt with in the coded or compressed domain; that is, what is being switched are Encoded Streams and not Raw
> Streams.  In the remaining video cases, one certainly cannot disregard timing here (see below).
[BoB] I agree that any type of mixing typically cannot disregard timing, meaning that the input streams to be mixed have to be Source Streams rather than Raw Streams. Regarding "selection", I agree that such "selection" operation can very well act on Encoded Streams and is probably misleading and even out of scope in this section. What about avoiding "selection" altogether by describing the Figure in 2.1.4 as a simple mix of three Source Streams?

I think the latter part of that "selection" sentence, trying to describe an example of a conceptual Video Source Stream, would benefit from firstly move after the (audio-related) figure, and secondly need a better example that truly operates on Source Streams (not Encoded Streams) and adds some reasonable scenario. What about describing a video surveillance switch that works on Source Streams (input and output), where the output is selected based on some criteria, like a round-robin of the inputs or some (not further specified) "video activity"?

> I¹m also not sure that in an audio mixer it would be ³Raw Streams² that are being mixed.  Certainly, a useful audio mixer is
> timing-aware, and in that case it would mix multiple Source Streams into a resulting Source Stream, rather than multiple
> Raw Streams into a resulting Source Stream.
[BoB] I agree. Will change and add some clarifying text around it.
 
> Many media coding formats allow to include redundancy--be it in the form of in-media FEC like what is available in opus
> and ITU video codecs, or source-coding based error resilience redundancy (like intra macro blocks in any modern video
> video coding).  Perhaps it could be made clearer that ³without additional redundancy² explicitly excludes these
> techniques--in other words, the term redundancy here refers exclusively to redundancy added through FEC, duplication,
> re-transmission and similar RTP-based tools.  Perhaps best would be to make it clear that most suitable Media Encoders
> add some redundancy into Encoded Streams to make them cope better with inevitable losses of RTP, but that there are
> in addition ways (discussed later) to add further redundancy protecting the RTP stream itself (rather than the Encoded
> Stream).
[BoB] Agree that the intent of "redundancy" in this context is RTP-level and does not include any redundancy that may be in the Encoded Stream itself. I will try to make this more clear in the next version.

> For anyone who worked on joint source-channel coding and optimization, the term ³Media Redundancy² is not intuitive
> here; in fact, many would consider it plainly inappropriate.  
[BoB] Then we should change it.

> The redundancy introduced in this section is added on the
> transport and generally protects transport units, namely sequences of RTP packets (that it also happens to protect the
> Encoded Stream carried in the RTP Stream² is a wanted side effect.) I had a short discussion about that term with Bo.  He
> said that a lot of mobile folks would find ³Transport Redundancy² also incomplete, as many folks would associate such
> term with radio layer stuff.  Perhaps ³RTP-based Redundancy²?
[BoB] That is probably a good-enough term, and I have no better proposal. Will change.

> 
> 5. 2.1.18, result of a failed checksum test Bo and I had a discussion about that as well, and I¹m happy to see that the harsh
> language of previous drafts is gone (in previous drafts, packets that fail checksum tests are dropped, period--ignoring
> things like UDP-lite).  Perhaps it may be worth mentioning that sensible system designs either drop packets, or flag the
> questionable packets in the resulting Received RTP Stream somehow so to alarm a Media Decoder about the possible
> corrupt state.  (That said, the media decoder needs to be error tolerant anyway, as in bit error prone networks the
> chance of a packet with passed UDP checksum still including bit errors is quite high.
[BoB] Sounds very reasonable. I will change text accordingly.

> 
> 6. 2.1.21 ³Media Repair²
> This section title has a similar problem as ³Media Redundancy.  Most joint source-channel coding folks would associate
> with the term ³media repair² things like error concealment, interpolation, ...) and not the application of FEC that is being
> sent outside of the Encoded Stream.  So different terminology is needed, and it should be aligned with the outcome of
> the ³Media Redundancy² discussion.  Further, what really is repaired here is the received RTP Stream itself and not the
> Received Source Stream; at least not directly.  So I guess, the right way to express this would be as
> follows:  RTP Stream Repair is the Transformation that takes as input one or more received Source RRP Streams and
> received Redundancy RTP Streams, and produces one or more Received RTP Streams that are as close to the sent Source
> RTP Streams as possible (utilizing FEC repair, retransmission, whatever).²
[BoB] OK. Will consequently change the title to "RTP-based Repair". Would like to keep "Repaired RTP Streams" as transformation output (there is a separate section on that and their relation to Received RTP Streams), but the rest of the text suggested above seems OK.

> Remove the note, and pick one (soon).
[BoB] Will do. I really prefer the one-word "Endpoint" and will send a separate mail to the list on this topic.

> 
> 8. Section 3, header
> change section title to ³Concepts of Inter-Relations² (add the ³of²) Overall, I find this section (not its subsections) overly
> abstract and also hard to read, but have no suggestions to improve it.
[BoB] Will change the title. I will try to improve and simplify the text - I'd actually expect that most of it is anyway covered elsewhere and can be removed.

> >to whether you regard it as editorial, minor technical, or a rather
> >more major flaw.
> >
> >Regards
> >
> >Keith
> >
> >http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonom
> >y-0
> >3
> >
> >

---

From: Bo Burman <[email-masked]>
Date: Thu, 27 Nov 2014 14:44:24 +0000

OK!

> Sent: den 18 november 2014 18:06
> To: [email-masked]
> One more.
> 9. Section 3.5 defines the three new categories for layered transmission (MRST, MRMT, and SRST, as [... On a
> [single/multiple] "Transport[s]".
> That should me "Media Transport[s]".
> Thanks,
> Stephan
> 
> >I read through this draft once more, and have a few remaining comments
> >(a few others were previously communicated to Bo in private and are
> >adequately addressed).
> >
> >impose constraints on the clock handling in some of the future steps.
> >For example, many audio Video Capture devices are not completely free
> >in selecting the sample rate.²
> >
> >2. Section 2.1.4, mixing
> >Streams and not Raw Streams.  In the remaining video cases, one
> >certainly cannot disregard timing here (see below).
> >are being mixed.  Certainly, a useful audio mixer is timing-aware, and
> >in that case it would mix multiple Source Streams into a resulting
> >Source Stream, rather than multiple Raw Streams into a resulting Source Stream.
> >
> >Many media coding formats allow to include redundancy--be it in the
> >form of in-media FEC like what is available in opus and ITU video
> >codecs, or source-coding based error resilience redundancy (like intra
> >macro blocks in any modern video video coding).  Perhaps it could be
> >made clearer that ³without additional redundancy² explicitly excludes
> >these techniques--in other words, the term redundancy here refers
> >exclusively to redundancy added through FEC, duplication,
> >re-transmission and similar RTP-based tools.  Perhaps best would be to
> >make it clear that most suitable Media Encoders add some redundancy
> >into Encoded Streams to make them cope better with inevitable losses of
> >RTP, but that there are in addition ways (discussed later) to add
> >further redundancy protecting the RTP stream itself (rather than the Encoded Stream).
> >
> >For anyone who worked on joint source-channel coding and optimization,
> >the term ³Media Redundancy² is not intuitive here; in fact, many would
> >section is added on the transport and generally protects transport
> >units, namely sequences of RTP packets (that it also happens to protect
> >the Encoded Stream carried in the RTP Stream² is a wanted side effect.)
> >I had a short discussion about that term with Bo.  He said that a lot
> >of mobile folks would find ³Transport Redundancy² also incomplete, as
> >many folks would associate such term with radio layer stuff.  Perhaps
> >³RTP-based Redundancy²?
> >
> >5. 2.1.18, result of a failed checksum test Bo and I had a discussion
> >about that as well, and I¹m happy to see that the harsh language of
> >previous drafts is gone (in previous drafts, packets that fail checksum
> >tests are dropped, period--ignoring things like UDP-lite).  Perhaps it
> >may be worth mentioning that sensible system designs either drop
> >packets, or flag the questionable packets in the resulting Received RTP
> >Stream somehow so to alarm a Media Decoder about the possible corrupt
> >state.  (That said, the media decoder needs to be error tolerant
> >anyway, as in bit error prone networks the chance of a packet with
> >passed UDP checksum still including bit errors is quite high.
> >
> >6. 2.1.21 ³Media Repair²
> >This section title has a similar problem as ³Media Redundancy.  Most
> >joint source-channel coding folks would associate with the term ³media
> >repair² things like error concealment, interpolation, ...) and not the
> >application of FEC that is being sent outside of the Encoded Stream.
> >So different terminology is needed, and it should be aligned with the
> >outcome of the ³Media Redundancy² discussion.  Further, what really is
> >repaired here is the received RTP Stream itself and not the Received
> >Source Stream; at least not directly.  So I guess, the right way to
> >express this would be as
> >follows:  RTP Stream Repair is the Transformation that takes as input
> >one or more received Source RRP Streams and received Redundancy RTP
> >Streams, and produces one or more Received RTP Streams that are as
> >close to the sent Source RTP Streams as possible (utilizing FEC repair,
> >retransmission, whatever).²
> >
> >>It is helpful to give some assessment of the nature of your comment,
> >>as to whether you regard it as editorial, minor technical, or a rather
> >>more major flaw.
> >>
> >>Regards
> >>
> >>Keith
> >>

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 27 Nov 2014 21:59:03 +0000

Hi Bo,
Thanks for addressing these points.  One small input for point 2 below
inline.
Stephan

On 11/27/14, 6:27, "Bo Burman" <[email-masked]> wrote:

>> Subject: Re: [avtext] I-D Action:
>>(a few others were previously communicated
>>[...]
>>(most? all?) video related cases, the ³selection² is
>[BoB] I agree that any type of mixing typically cannot disregard timing,
>meaning that the input streams to be mixed have to be Source Streams
>rather than Raw Streams. Regarding "selection", I agree that such
>"selection" operation can very well act on Encoded Streams and is
>probably misleading and even out of scope in this section. What about
>avoiding "selection" altogether by describing the Figure in 2.1.4 as a
>simple mix of three Source Streams?
>
>I think the latter part of that "selection" sentence, trying to describe
>an example of a conceptual Video Source Stream, would benefit from
>firstly move after the (audio-related) figure, and secondly need a better
>example that truly operates on Source Streams (not Encoded Streams) and
>adds some reasonable scenario. What about describing a video surveillance
>switch that works on Source Streams (input and output), where the output
>is selected based on some criteria, like a round-robin of the inputs or
>some (not further specified) "video activity"?

I did not consider the switching/selection activity you had in mind.  Yes,
the type of video selection you describe still exists in practice.  So I
guess I would like to withdraw my comment #2 in its entirety.  Perhaps add
the surveillance switch as an example, though.

>[...]