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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------