Re: [payload] Review of draft-ietf-payload-flexible-fec-scheme-08

[Giridhar Mandyam <[e-mail]>]

Hello Magnus,
Thank you for your continued detailed review.  

Our apologies for not responding to you prior to posting the latest revision.  We were trying to get it uploaded prior to the submission tool closing.  Before posting a new revision, I would like to get confirmation from you on the necessary changes.

-Giri Mandyam

<-------->

Original comment:  Section 4.2.2.3: Are there any assumptions about the relation between repair RTP stream SSRC and the source RTP stream SSRC? The text here appears to indicate that it can be 1 (repair stream) sending retransmission packets for many source RTP streams? Can you please clarify this.

Are there a point of doing this type of retransmission in a 1 to 1 fashion instead?

Revised text:  "Note that the retransmission packet corresponds only to a single source SSRC."

Feedback:  > I don't understand what this sentence means. I think you need either of two statements to make this clear. ...

Proposed replacement text:  "When performing retransmissions of single source packets, a unique repair packet stream (SSRC) MUST be used for each source packet stream (SSRC) to enable efficient handling after the first initial repair packet on each SSRC."

Author's response:  Your option A) better encompassed our original intent.

<-------->

Original comment:  " o  ToP: indicates the type of protection applied by the sender: ... "

What about retransmission only uses? And what about combinations with retransmission and other types?

Revised text:  "ToP: indicates the type of protection applied by the sender: ... 3 for retranmission"

Feedback:  > Note spelling error in retran(s)mission!  However, this enables a PT to be configured for retransmission use. It still doesn't make it clear if ToP=0,3 would be allowed or not. I don't see any problem in requiring a single value per PT. But please be explicit about that limitation.

Proposed replacement text:  Correct spelling error, and add "There can only be one value listed for ToP."

Author's response:  A single value of ToP per payload type was the original intent.

<-------->

Original comment:  Section 7.  I think this section is missing the discussion of the need to signal the RTP session relation between source and repair RTP Streams. ...

Revised text:  " Out-of-band signaling should be designed to enable the receiver to identify the RTP streams associated with source packets and repair packets, respectively.  ..."

Feedback:  > I think the above text is actually making the requirements stricter than necessary and also beyond SDP's capability in some cases depending on its use.

Proposed replacement text:  Eliminate " Note that other approaches to RTP stream identification SHOULD NOT be used for the purposes of FLEX FEC." in revision

Author's response:  Agree that original text is overly restrictive.



-----Original Message-----
From: Magnus Westerlund <[e-mail]> 
Sent: Thursday, October 25, 2018 5:34 AM
To: [e-mail]; [e-mail]
Subject: Re: [payload] Review of draft-ietf-payload-flexible-fec-scheme-08

Hi,

I have looked at the new version -09 and see if it addresses my issues:


On 2018-07-17 20:22, Magnus Westerlund wrote:

G. Section 4.2.2.3:

Are there any assumptions about the relation between repair RTP stream SSRC and the source RTP stream SSRC? The text here appears to indicate that it can be 1 (repair stream) sending retransmission packets for many source RTP streams? Can you please clarify this.

Are there a point of doing this type of retransmission in a 1 to 1 fashion instead?


So what I understand what got changed due to this comment was:

Note that the
   retransmission packet corresponds only to a single source SSRC.



I don't understand what this sentence means. I think you need either of two statements to make this clear.

A) When performing retransmissions of single source packets, a unique repair packet stream (SSRC) MUST be used for each source packet stream (SSRC) to enable efficient handling after the first initial repair packet on each SSRC.

B) When performing retransmissions, a single repair packet stream (SSRC) MAY be used for retransmitting packets from multiple source packet streams (SSRCs).

I prefer A as it enables smarter processing for those who want to, but as each retransmission packet are self identifying, an implementation can choces to basically do what B) implies, namely determine first that it is a retransmission packet, then decapsulate it and restore the retransmitted packet and then handle it as a totally new incoming packet that need to be routed to the packet stream. A) enables an implementation freedom to do early binding on the associated repair stream SSRC.



H. Section 5.1:

   o  ToP: indicates the type of protection applied by the sender: 0 for
       1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
       protection, and 2 for 2-D parity FEC protection.  The ToP value of
       3 is reserved for future uses.

What about retransmission only uses? And what about combinations with retransmission and other types?


The change:

   o  ToP: indicates the type of protection applied by the sender: 0 for
      1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC
      protection, 2 for 2-D parity FEC protection, and 3 for
      retranmission.



Note spelling error in retran(s)mission!


However, this enables a PT to be configured for retransmission use. It still doesn't make it clear if ToP=0,3 would be allowed or not. I don't see any problem in requiring a single value per PT. But please be explicit about that limitation.



N. Section 7:

I think this section is missing the discussion of the need to signal the RTP session relation between source and repair RTP Streams. There is basically two choices here, either the repair RTP stream(s) are in the same RTP Session as the source packets, or they are in a different one.

When they are in the same, it is clear that the packets carry the
SSRC(s) of the source RTP packets. However, one thing is a bit unclear and could vary with implementation and that is the number of repair RTP streams in use when there are multiple source RTP streams. Are there only one repair stream, or one per source RTP stream or some other relation? So example 7.1 could be one or more source RTP stream but nothing in the signalling reveals this. Signalling context can make it clear if there is a single media source or could be more. For 7.2 there is an explicit binding between the repair and source SSRCs.

I think the need and not need to explicitly indicate the source to repair stream relations.


For different RTP sessions there need to be some type of RTP/RTCP out of band mechanism to indicate the relation.  The use of grouping of media lines FEC semantics is very reasonable and should be made clear and probably include an example.

I would prefer if the signalling requirements where discussed first, followed by SDP related mechanisms then followed by the examples of the realization.

Good initial stab on the signalling requirements.

7.  Signaling Requirements

   Out-of-band signaling should be designed to enable the receiver to
   identify the RTP streams associated with source packets and repair
   packets, respectively.  At a minimum, the signaling must be designed
   to allow the receiver to

   o  Determine whether one or more source RTP streams will be sent.

   o  Determine whether one or more repair RTP streams will be sent.

   o  Associate the appropriate SSRC's to both source and repair
      streams.

   o  Clearly identify which SSRC's are associated with each source
      block.

   o  Clearly identify which repair packets correspond to which source
      blocks.

   o  Make use of repair packets to recover source data associated with
      specific SSRC's.

   This section provides several Sesssion Description Protocol (SDP)
   examples to demonstrate how these requirements can be met.  Note that
   other approaches to RTP stream identification SHOULD NOT be used for
   the purposes of FLEX FEC.


I think the above text is actually making the requirements stricter than necessary and also beyond SDP's capability in some cases depending on its use