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

[Magnus Westerlund <[e-mail]>]

On 2018-10-26 22:12, Giridhar Mandyam wrote:
> 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.

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


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

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


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


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


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

-- 

Magnus Westerlund 

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