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

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the updated draft -08. So now I finally done a complete 
review from front to end. Sorry about the delay to get these comments in.


A. Section 4.2.1:

       Synchronization Source (SSRC): The SSRC value for each repair
       stream SHALL be randomly assigned as suggested by [RFC3550].  This
       allows the sender to multiplex the source and repair RTP streams
       on the same port, or multiplex multiple repair streams on a single
       port.  The repair streams SHOULD use the RTCP CNAME field to
       associate themselves with the source stream.

Instead of port in this text, I think what you want to refer to RTP 
sessions. Maybe:

       Synchronization Source (SSRC): The SSRC value for each repair
       stream SHALL be randomly assigned as suggested by [RFC3550].  This
       allows the sender to multiplex the source and repair RTP streams
       in the same RTP session, or multiplex multiple repair streams in 
an RTP session.


B. Section 4.2.1:

       The repair streams SHOULD use the RTCP CNAME field to
       associate themselves with the source stream.

So in cases when the host sends multiple source RTP streams, the CNAME 
only results in the repair stream being associated with a set of source 
RTP Streams through common CNAME. After all the actual source RTP stream 
is identified explicitly. There will also occur none-resolvable cases 
when a inline FEC producer includes source packets from multiple 
different hosts, and thus likely different CNAMEs.

I think the right way forward here is to say that the repair RTP streams 
SSRC's CNAME value SHOULD be identical to the CNAME of the source RTP 
stream(s) that this repair stream protects. In cases when the repair 
stream covers packets from multiple source RTP streams with different 
CNAME, any CNAME value MAY be used.

Also maybe the text following on inline FEC protectors should be 
changed, so that they would use its own CNAME so that one can determine 
if the transmission timestamp clock really is the same as the one used 
for the source RTP Streams?

C. Section 4.2.2.1:

   o  The Length recovery (16 bits) field is used to determine the
       length of the recovered packets.  This length includes all octets
       following the fixed 12-byte RTP header of source packets,
       including CSRC list and options if present.  It excludes the fixed
       12-byte RTP header of source packets.

"Options" in the above, is that intended to be header extensions?

D. Section 4.2.2.2:

There is no formal definition here for how the source block is created 
when there are multiple SSRCs in the CSRC list.

E. Section 4.2.2.2:
      |    ... next SN base and M/N for CSRC_i in CSRC list ... |

What is M/N is it supposed to be L and D?

F. Section 4.2.2.2:

    If L>0, D=1, indicates Row FEC, and column FEC will follow.
                 Hence, FEC = SN, SN+1, SN+2, ... , SN+(L-1), SN+L.
                 And more FEC to come.

What does "more FEC to come means here?" Without explicit definition I 
don't see what difference this has to L>0, D=0?


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?

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?

I. Section 5.1:

    o  L: indicates the number of columns of the source block that are
       protected by this FEC block and it applies to all the source
       SSRCs.  L is a positive integer.

    o  D: indicates the number of rows of the source block that are
       protected by this FEC block and it applies to all the source
       SSRCs.  D is a positive integer.

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

Section 4.2.2.2:
    If L=0, D=0, use the optional payload format parameters for L and D.

I don't quite understand how a receiver will be able to determine which 
packets where part of the source block to generate this FEC packet. L 
and D will only specify the size of the block, but there is no 
information if this is a row or column packet for the 2-D ones. Or is 
the intention that these will only be 1-D codes, and the row or column 
mode will be based on the value of the Media Type parameters of L and D? 
Section 6.3.1.3 implies that only a 1-D code is supported in this use 
case. Please document that restriction with the signalling parameters.

J. Section 5.2.1

    o  There are no optional format parameters defined for this payload.

Isn't L, D and ToP optional parameters.

K. Section 6.2:
    o  The lowest Sequence Number of the source packets protected by this
       repair packet is written into the Sequence Number Base field in
       the FEC header.

    o  Depending on the chosen FEC header variant, the mask(s) are set
       when F=0, or the L and D values are set when F=1.

These steps needs to be repeated for each SSRC that has packets included 
in the source block.

L. Section 6.3.1:

I think this text is missing the really first step of the receiver 
knowing in which RTP sessions the source and repair RTP streams that are 
related are being sent in. This may be different or the same session as 
indicated by signalling or other out-of-bands means.

M. Section 6.3.2:

    14.  Set the SSRC of the new packet to the SSRC of the source RTP
         stream.

Maybe to be even more explicit to say, the SSRC of the missing source 
RTP stream, to avoid confusion in multiple SSRC source blocks.

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.


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.

P. Section 9.

Is there a need to discuss in the security consideration the risk that 
additional source RTP streams can result in creation of buffers that may 
or may not be used. Also the FEC has a non uniform processing 
requirement that may affect the higher layer application.

Cheers---

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------