Subject: Re: [payload] [rtcweb] Second WGLC on draft-ietf-payload-flexible-fec-scheme

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Jun 2018 16:15:10 +0200

Hi,

I have now reviewed -07. It is not ready yet. A significant issue appear 
to exist around how one recovers CSRC lists or header extensions.

1. Section 4.2.2, Figure 13:

The R and F bits are swapped. To my understanding this figure should use 
R=0 and F=1, i.e. 0 1 in the two first bits.

2. Section 4.2.2, Figure 15:

So when R=1, why is F=1? As neither of the F values apply when R=1, why 
not simply define that F=0, which would result in that the RTP payload 
would be equal to the complete RTP packet being retransmitted?

3. Section 4.2.2, Figure 15:

Why isn't the CSRC list or packet header extension of the retransmitted 
packet included in the figure, they will be there if P or X bits of the 
Retransmission is present? Or are they counted as part of the 
retransmission / repair payload?

4. Section 6.2:

    The repair packet payload consists of the bits that are generated by
    applying the XOR operation on the payloads of the source RTP packets.
    If the payload lengths of the source packets are not equal, each
    shorter packet MUST be padded to the length of the longest packet by
    adding octet 0's at the end.

The repair packet does not appear to protect the source packets packet 
extension or CSRC list. I think what is missing here is the need to be 
explicit that the repair payload will be XOR of the source packets' CSRC 
list, extension header and payload?

The reverse thus need to be explicitly said in the recovery section also.

Cheers

Magnus

Den 2018-03-22 kl. 17:41, skrev Roni Even (A):
>
> Hi,
>
> I would like to start a three week second WGLC on RTP Payload Format 
> for Flexible Forward Error Correction in 
> draft-ietf-payload-flexible-fec-scheme-07 
> <https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-07>.
>
> The WGLC will end on April 11^th , 2018
>
> Note that the first WGLC was on the 05 version  and the 06,07 are 
> incremental updates.
>
> The slides from the IETF 101 payload session describe the changes see 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexible-fec-00 
> .
>
> Please send comments to the payload mailing list.
>
> The double posting is to  notify RTCweb WG that the second  WGLC has 
> started since this document is needed for RTCweb
>
> Roni Even
>
> Payload WG co-chair
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 19 Jun 2018 05:09:29 +0000

Hi Mo,
I hope you noticed Magnus comments
Can you please respond.
I will be happy if we can finish the work on this document soon
Roni Even (A)
Payload WG co-chair

From: payload [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Monday, June 11, 2018 5:15 PM
To: [email-masked]
Subject: Re: [payload] [rtcweb] Second WGLC on draft-ietf-payload-flexible-fec-scheme

Hi,

I have now reviewed -07. It is not ready yet. A significant issue appear to exist around how one recovers CSRC lists or header extensions.

The R and F bits are swapped. To my understanding this figure should use R=0 and F=1, i.e. 0 1 in the two first bits.

So when R=1, why is F=1? As neither of the F values apply when R=1, why not simply define that F=0, which would result in that the RTP payload would be equal to the complete RTP packet being retransmitted?

Why isn't the CSRC list or packet header extension of the retransmitted packet included in the figure, they will be there if P or X bits of the Retransmission is present? Or are they counted as part of the retransmission / repair payload?

4. Section 6.2:

The repair packet does not appear to protect the source packets packet extension or CSRC list. I think what is missing here is the need to be explicit that the repair payload will be XOR of the source packets' CSRC list, extension header and payload?

Cheers

Magnus

Hi,
I would like to start a three week second WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-07<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-07>.
The WGLC will end on April 11th , 2018

Note that the first WGLC was on the 05 version  and the 06,07 are incremental updates.
The slides from the IETF 101 payload session describe the changes see https://datatracker.ietf.org/meeting/101/materials/slides-101-payload-flexible-fec-00 .

Please send comments to the payload mailing list.
The double posting is to  notify RTCweb WG that the second  WGLC has started since this document is needed for RTCweb

Roni Even
Payload WG co-chair

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

--

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>