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

["Mo Zanaty (mzanaty)" <[e-mail]>]

WG,

After discussing version -10 changes with Magnus and Jonathan, one change
needs to be modified.

OLD:
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.

NEW:
When performing retransmissions, a single repair packet stream (SSRC) MAY
be used for retransmitting packets from multiple source packet streams
(SSRCs), as well as transmitting FEC repair packets that protect multiple
source packet streams (SSRCs).

This replaces option A) with B) from Magnus' original comments, so a
single repair SSRC can retransmit multiple source SSRCs, and further
clarifies that the single repair SSRC can be used for both retransmission
and FEC protection of multiple source SSRCs.


Please comment if there are any objections, otherwise the authors will
make this change in -11.

Thanks,
Mo

-----Original Message-----
From: 'Magnus Westerlund' <[e-mail]>
Date: Thursday, October 25, 2018 at 7:33 AM
To: "[e-mail]" <[e-mail]>rg>,
"[e-mail]"
<[e-mail]>
Subject: Re: [payload] Review of draft-ietf-payload-flexible-fec-scheme-08
Resent-From: <[e-mail]>
Resent-To: mzanaty <[e-mail]>om>, <[e-mail]>fi>,
<[e-mail]>ia>, <[e-mail]>
Resent-Date: Thursday, October 25, 2018 at 7:33 AM

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