Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Feb 2015 14:08:32 -0800

I  have a comment on the use of the term "redundancy" in the draft.   There is no definition of the term in the document, and even after reading it, I was not clear whether the term was referring specifically to redundant data (RFC 2198) or perhaps more generally to robustness mechanisms in general, including Forward Error Correction (FEC) (e.g. RFC 5109), retransmission (e.g. RFC 4588), etc. 
 
In particular, these mechanisms differ in a number of potentially relevant dimensions, such as their compatibility with BUNDLE.

---

From: Bo Burman <[email-masked]>
Date: Tue, 3 Feb 2015 08:20:40 +0000

It would of course be possible to define the use of the term "redundancy" in the document, but I think it should already be pretty clear from sections 2.1.11 and 2.1.12 that the intention is to cover the more general robustness mechanisms:

2.1.11.  RTP-based Redundancy

   RTP-based Redundancy is defined here as a transformation that
   generates redundant or repair packets sent out as a Redundancy RTP
   Stream (Section 2.1.12) to mitigate network transport impairments,
   like packet loss and delay.

   The RTP-based Redundancy exists in many flavors; they may be
   generating independent Repair Streams that are used in addition to
   the Source Stream (like RTP Retransmission (Section 3.11) and some
   special types of Forward Error Correction, like RTP stream
   duplication (Section 3.9)), they may generate a new Source Stream by
   combining redundancy information with source information (Using XOR
   FEC (Section 3.12) as a redundancy payload (Section 3.10)), or
   completely replace the source information with only redundancy
   packets.

2.1.12.  Redundancy RTP Stream

   A RTP Stream (Section 2.1.10) that contains no original source data,
   only redundant data that may be combined with one or more Received
   RTP Stream (Section 2.1.19) to produce Repaired RTP Streams
   (Section 2.1.22).

Referring to the above text, can you please be more explicit in what you think is unclear, or what could be changed to be more clear?

/Bo

From: avtext [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: den 2 februari 2015 23:09
To: [email-masked]
Subject: Re: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05

---

From: Bo Burman <[email-masked]>
Date: Mon, 9 Feb 2015 11:33:49 +0000

My views, inline below. /Bo

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: den 30 januari 2015 16:39
> To: [email-masked]
> Subject: [avtext] Comments on draft-ietf-avtext-rtp-grouping-taxonomy-05
> 
> Hi,
> 
> I have just reviewed draft-ietf-avtext-rtp-grouping-taxonomy-05 and think it is in good shape. However, I do have some
> few comments and reflections for the WG to consider.
> 
> 1. The case when there are no source RTP stream, only redundancy RTP streams. This relates to two different sections:
> 
> 2.1.21.  RTP-based Repair
>    RTP-based Repair is a Transformation that takes as input one or more
>    Received RTP Streams (Section 2.1.19) and Received Redundancy RTP
>    Streams (Section 2.1.20), and produces one or more Repaired RTP
>    Streams (Section 2.1.22) that are as close to the corresponding sent
>    Source RTP Streams (Section 2.1.10) as possible, using different RTP-
>    based repair methods, for example the ones referred in RTP-based
>    Redundancy (Section 2.1.11).
> 
> I think the formulation is likely to allow for this case when one applies a FEC transform that results in no source RTP
> stream only redundancy symbols that are encoded into a Redundancy RTP stream.
> 
> In 2.1.12 the important part is: ... only redundant data that may be combined with one or more Received RTP Stream
> (Section 2.1.19) ...
> The "may" here allows the case for no other stream to combine it with.
> 
> In 2.1.21 the text I react to is: "... that takes as input one or more
>    Received RTP Streams (Section 2.1.19) and Received Redundancy RTP
>    Streams (Section 2.1.20), ..."
> 
> This text is not super clear that what we are talking about are 1*(Recevied_RTP_Stream |
> Received_Redundancy_RTP_Stream)
> 
> It is not that the case for no source stream is ruled out, but it also not clear and thus easily missed that this may occur. So
> either some informative sentence about this case, or maybe clarifying in 2.1.21 that it is zero or more Received RTP
> Streams and 1 or more Received Redundancy RTP to create a Repaired RTP stream.

[BoB] So, could we make this more clear by being explicit in 2.1.21? :
   RTP-based Repair is a Transformation that takes as input zero or more
   Received RTP Streams (Section 2.1.19) and one or more Received Redundancy RTP
   Streams (Section 2.1.20)...

In that case, I'd also suggest that we are similarly explicit in 2.1.12:
   A RTP Stream (Section 2.1.10) that contains no original source data,
   only redundant data, which may either be used standalone or be combined with one or more Received
   RTP Streams (Section 2.1.19) to produce Repaired RTP Streams
   (Section 2.1.22).

> 2. Figure 6:
> 
>       +------------------------------------------------------------+
>       | Communication Session                                      |
>       |                                                            |
>       | +----------------+                      +----------------+ |
>       | | Participant A  |    +------------+    | Participant B  | |
>       | |                |    | Multimedia |    |                | |
>       | | +-------------+|<==>| Session    |<==>|+-------------+ | |
>       | | | Endpoint A  ||    |            |    || Endpoint B  | | |
>       | | |             ||    +------------+    ||             | | |
>       | | | +-----------++----------------------++-----------+ | | |
>       | | | |            |                      |            | | | |
>       | | | | RTP Session|---Media Transport--->|            | | | |
>       | | | | Audio      |<---Media Transport---|            | | | |
>       | | | |            |          ^           |            | | | |
>       | | | +-----------++----------|-----------++-----------+ | | |
>       | | |             ||          v           ||             | | |
>       | | |             || +-----------------+  ||             | | |
>       | | |             || | Synchronization |  ||             | | |
>       | | |             || |     Context     |  ||             | | |
>       | | |             || +-----------------+  ||             | | |
>       | | |             ||          ^           ||             | | |
>       | | | +-----------++----------|-----------++-----------+ | | |
>       | | | |            |          v           |            | | | |
>       | | | | RTP Session|<---Media Transport---|            | | | |
>       | | | | Video      |---Media Transport--->|            | | | |
>       | | | |            |                      |            | | | |
>       | | | +-----------++----------------------++-----------+ | | |
>       | | +-------------+|                      |+-------------+ | |
>       | +----------------+                      +----------------+ |
>       +------------------------------------------------------------+
> 
> What I am reacting to is that the Media Transports are terminated against the Participant line rather than the endpoint
> line. I would prefer that they would terminate at that level.
> 
> This could look like this:
> 
>       +------------------------------------------------------------+
>       | Communication Session                                      |
>       |                                                            |
>       | +----------------+                      +----------------+ |
>       | | Participant A  |    +------------+    | Participant B  | |
>       | |                |    | Multimedia |    |                | |
>       | | +-------------+|<==>| Session    |<==>|+-------------+ | |
>       | | | Endpoint A  ||    |            |    || Endpoint B  | | |
>       | | |             ||    +------------+    ||             | | |
>       | | | +-----------++----------------------++-----------+ | | |
>       | | | |           ||                      ||           | | | |
>       | | | |RTP Session|----Media Transport---->|           | | | |
>       | | | |Audio      |<---Media Transport-----|           | | | |
>       | | | |           ||          ^           ||           | | | |
>       | | | +-----------++----------|-----------++-----------+ | | |
>       | | |             ||          v           ||             | | |
>       | | |             || +-----------------+  ||             | | |
>       | | |             || | Synchronization |  ||             | | |
>       | | |             || |     Context     |  ||             | | |
>       | | |             || +-----------------+  ||             | | |
>       | | |             ||          ^           ||             | | |
>       | | | +-----------++----------|-----------++-----------+ | | |
>       | | | |           ||          v           ||           | | | |
>       | | | |RTP Session|<---Media Transport-----|           | | | |
>       | | | |Video      |----Media Transport---->|           | | | |
>       | | | |           ||                      ||           | | | |
>       | | | +-----------++----------------------++-----------+ | | |
>       | | +-------------+|                      |+-------------+ | |
>       | +----------------+                      +----------------+ |
>       +------------------------------------------------------------+
[BoB] I have no objections to making that change. 

> 
> 3. Section 2.2.1
> 
>    o  An Endpoint can be associated with at most one Participant
>       (Section 2.2.3) at any single point in time.
> 
>    o  In some contexts, an Endpoint would typically correspond to a
>       single "host", for example a computer using a single network
>       interface and being used by a single human user.
> 
> I think we might need to clarify how one should consider endpoints in the following scenario.
> 
> A multi-user host, where two participants are communicating with each other using T.140 text (To avoid i/o issues of
> multi-user environments).
> The first bullet above requires then this host two have two endpoints. I think the current intuitive feeling for endpoint is
> that is it can be identified by an network address. However, if the above case are two endpoints they may actually have
> the same network address.
> 
> I believe the most simple solution going forward would be to make it clear that in some cases there be multiple
> endpoints at a single host. I would propose to add to the second bullet above the following:
> 
>     In other contexts, a single 'host' can serve multiple Participants,
>     in which case each Participant's Endpoint may share properties, for
>     example the IP address part of a transport address.
[BoB] Looks good to me (adding a seemingly missing "example" as first word on last line of the proposed text)

> 
> 
> 4. section 3.5:
> 
>    2.  In Multi-Session Transmission (MST), the SVC Media Encoder sends
>        Encoded Streams and Dependent Streams distributed across multiple
>        RTP Streams in one or more RTP Sessions.
> 
> and
> 
>    MST denotes one or more RTP Streams (SSRC) per Media Source
>    in each of multiple RTP Sessions.
> 
> Is these two sentence really consistent. It is less than clear that "multiple" is equivalent to "one or more".
[BoB] I think at least the first sentence is clear, but I don't think "multiple" should be read as "one or more", rather "two or more". The second sentence is less clear, in that it seems to actually require two or more RTP Sessions (still assuming that "multiple" is not "one or more" but rather "two or more"). That single, short sentence seemingly tries to cover two cases (both per Media Source): 1) Two or more RTP Streams in one or more RTP Sessions, and 2) One or more RTP Streams in each of two or more RTP Sessions. I suggest to make those clarifications, using "one or more" and "two or more" wordings instead of "multiple".

> 
> 
> 5. section 3.5:
> 
> I wonder if we should at this stage create a special version of MRMT which has one and only one RTP stream per Media
> Source and media transport? The reason for such a one is exactly the discussion held in Section 3.8 about using the same
> SSRC value in multiple RTP sessions.
[BoB] I don't see any strong need to introduce any new acronym for this, but encourage others to comment.

> 
> 6. Section 3.7:
> 
> As MDC is used in three places only, I think a reference is needed for the occurrence here in Section 3.7 back to Section
> 2.1.6.
[BoB] I have no problems adding a reference back to 2.1.6.

> 
> 
> I will be away next week, so I will follow up on this after the 8th of February.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Feb 2015 16:49:10 +0100

Hi,

Please see inline for responses.

>    Streams (Section 2.1.20)...

Sounds good!

>    RTP Streams (Section 2.1.19) to produce Repaired RTP Streams

Yes, that would work.

> [BoB] Looks good to me (adding a seemingly missing "example" as first word on last line of the proposed text)

Good!

> [BoB] I think at least the first sentence is clear, but I don't
> think "multiple" should be read as "one or more", rather "two or more". The
> second sentence is less clear, in that it seems to actually require two
> or more RTP Sessions (still assuming that "multiple" is not "one or
> more" but rather "two or more"). That single, short sentence seemingly
> tries to cover two cases (both per Media Source): 1) Two or more RTP
> Streams in one or more RTP Sessions, and 2) One or more RTP Streams in
> each of two or more RTP Sessions. I suggest to make those
> clarifications, using "one or more" and "two or more" wordings instead
> of "multiple".

Sounds okay to me.

> [BoB] I don't see any strong need to introduce any new acronym for this, but encourage others to comment.

Yes, please provide input into this question.

Cheers

Magnus Westerlund

---

From: Bo Burman <[email-masked]>
Date: Fri, 20 Feb 2015 08:14:15 +0000

WG, I am about to make a -06 version taking Magnus' comments into account, and would like your guidance on how to proceed with Magnus' question below (included mail shortened).

Cheers,
Bo

> From: Magnus Westerlund
> Sent: den 9 februari 2015 16:49
> To: Bo Burman; [email-masked]
 <snip>
> >> 5. section 3.5:
> >>
> >> I wonder if we should at this stage create a special version of MRMT
> >> which has one and only one RTP stream per Media Source and media
> >> transport? The reason for such a one is exactly the discussion held in Section 3.8 about using the same SSRC value in
> multiple RTP sessions.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Feb 2015 14:58:38 -0800

> > > [BoB] I don't see any strong need to introduce any new acronym for this, but encourage others to comment.

[BA] I don't see the need either.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 22 Feb 2015 11:24:43 -0800

A few comments on Section 3.5:  		 	   		  
3.5.  Single- and Multi-Session Transmission of Dependent Streams

   Scalable media coding formats such as, for example, H.264 based SVC
   [RFC6190] has two modes of operation:

   1.  In Single Session Transmission (SST), the SVC Media Encoder sends
       Encoded Streams (Section 2.1.7) and Dependent Streams
       (Section 2.1.8) as a single RTP Stream (Section 2.1.10) in a
       single RTP Session (Section 2.2.2), using the SVC RTP Payload
       format.

[BA] I do not believe this is accurate.  The term SST as defined in RFC 6190 appears to have different meanings within different sections of the document.  In sections relating to packetization, it appears to be synonymous with a single RTP Stream, since use of multiple streams requires support for the DON field.  However, in other sections (such in referring to SDP), the SST/MST terminology really does appear to refer to single versus multiple RTP sessions.  

   2.  In Multi-Session Transmission (MST), the SVC Media Encoder sends
       Encoded Streams and Dependent Streams distributed across multiple
       RTP Streams in one or more RTP Sessions.
[BA] The meaning of MST in RFC 6190 is not really that clear. If you are referring to use of the DON field, this is needed whenever multiple RTP streams are used regardless of whether we are talking about multiple RTP sessions or not.      
   SST denotes one RTP Stream (SSRC) per Media Source in a single RTP
   Session.  MST denotes one or more RTP Streams (SSRC) per Media Source
   in each of multiple RTP Sessions.  The above is not unambiguously
   specified in the SVC payload format text [RFC6190], but it is what
   existing deployments of that RFC have implemented.

[BA] The use of multiple RTP streams within a single RTP session is in fact implemented - this is what was implemented in Lync 2013. 
   The use of the term "RTP Session" in the SST/MST definition is
   somewhat misleading, since a single RTP Session can contain multiple
   RTP Streams.
[BA] My advice would be to point out the ambiguities in RFC 6190 SST/MST terminology, while not attempting to fix them retroactively.  Overall, it is more productiveto focus this document on the new  SRST/MRST/MRMT terminology.
   Also, it is sometimes useful to make a distinction
   between using a single Media Transport or multiple separate Media
   Transports when (in both cases) using multiple RTP Streams to carry
   Encoded Streams and Dependent Streams for a Media Source.  Therefore,
   herein the following new terminology is defined:

   SRST:  Single RTP Stream on a Single Media Transport

   MRST:  Multiple RTP Streams on a Single Media Transport

   MRMT:  Multiple RTP Streams on Multiple Media Transports