[payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

[Giridhar Mandyam <[e-mail]>]

Magnus,
Here is the proposal to respond to your comments in https://mailarchive.ietf.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.

Thanks,
-Giri Mandyam

A. > At least in discussing this with Mo F2F I got the impression that the plan was to also be explicit about what the lack of it (ToP) means, i.e. it can be any of the self describing usages, so a mix of retransmission and FEC is possible.

Proposed change:  The following sentence will be added to each ToP section:  " The absence of the ToP field means that all protection types are allowed."

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

Proposed Change #1:  Add a reference to https://tools.ietf.org/html/draft-ietf-avtext-rid-09 in the Informative References section.

Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP Stream Identifier Source Description", with the following text:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a format that can be used to identify a single RTP source stream along with an associated repair stream.  However, since this specification already defines a method of source and repair stream identification that can enable protection of 
Multiple source streams with a single repair stream.  Therefore the RTP Stream Idenfifer Source Description SHOULD NOT be used for the Flexible FEC payload format." 

-----Original Message-----
From: Roni Even (A) <[e-mail]> 
Sent: Thursday, December 6, 2018 3:03 AM
To: Magnus Westerlund <[e-mail]>; Giridhar Mandyam <[e-mail]>
Cc: Ali C. Begen <[e-mail]>; Mo Zanaty (mzanaty) <[e-mail]>; Ben Campbell <[e-mail]>; [e-mail]
Subject: RE: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-10.txt

Hi,
Can you send these messages to the list.
I am wondering about ToP, I saw a previous question from Magnus about using for example ToP 0,3 (FEC plus retransmission) not allowed by current definition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it is allowed I also assume that Magnus asked for the default value for ToP and I did not see any text in 5.1.1 Roni Even 


-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]]
Sent: Thursday, December 06, 2018 10:32 AM
To: Ben Campbell
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar Mandyam
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-10.txt

Hi,

I have responded on the first question. Although I don't understand why that went off-list.

I want to comment on the second paragraph below.

On 2018-12-05 19:36, Ben Campbell wrote:
>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <[e-mail]> wrote:
>>
>> I believe his first comment on ToP needs to be addressed in the revision.  I believe his second comment is more problematic, because it refers to a standards-track document that has not achieved RFC status yet (i.e. it may undergo changes), and I am not sure it will help the document.
>>
>>
Considering that draft-ietf-avtext-rid is approved and stuck in RFC-editor missref state on cluster 238 I don't see this as a reason for not addressing my raised issue.

The reason I do want to raise this is that flexfec could be used in a sub-set of cases, but is not necessary in any cases as the linking to the source flow is provided in the FLEXFEC RTP packet. Thus, for making it clear that it is not needed, I think an explicit statement should be added to that effect. If we don't have a statement we might find situations where people will attempt to apply it and gets into the confusion if they try the FEC mode with multiple source SSRCs where it doesn't work.

Cheers 

Magnus Westerlund 

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