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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Oct 2018 12:33:50 +0000

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.

There is also the fact that with flex fec and other mechanisms several of the above requirements are not necessary to do with out-of-band mechanisms. For example the source stream's actually repaired are provided explicitly in the repair packets. What the SDP signalling really indicates are to indicate which media sources (m= lines) where repair may be used. So SSRC signalling is possible, but not required. So, maybe there is need for some reformulation to say that what need to be possible is to indicate, but not required as sometimes the dynamic functions are used.

O. Section 7:
The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all
needed, even if it could be used in a sub-set of applications of
flexfec. It would work in same RTP Session, with a single repair RTP
stream only protects a singe source RTP stream. But, considering the
possibility of repair of multiple source streams and different RTP
Sessions, I think an explicit statement that this SHOULD NOT be used for
the payload format would be good to include.

This issue does not appear to have resulted in any changes nor been commented on.

--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 26 Oct 2018 20:12:36 +0000

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 <[email-masked]> 
Sent: Thursday, October 25, 2018 5:34 AM
To: [email-masked]; [email-masked]
Subject: Re: [payload] Review of draft-ietf-payload-flexible-fec-scheme-08

Hi,

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?

Note that the

H. Section 5.1:

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

The change:

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.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Oct 2018 10:01:21 +0000

> 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 t…

That is fine with me. I think it allows RTP steram level handling of the
repair streams relation to the source stream.

Fine, that makes usage visible on RTP level, rather than inside RTP
payload.

Ok.

Appears that then things are resolved. Looking forward to the update
then. So then I am expecting a new version early next week when the
submission has opened again.

Cheers

Magnus

-- 

Magnus Westerlund 

SE-164 80 Stockholm, Sweden | mailto: [email-masked]