Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC

[Emmanuel Lochin <[e-mail]>]

Hi Vincent,

I'm fine with all your answers/corrections.

Cheers

EL

Le 02/05/2018 à 11:24, Vincent Roca a écrit :
> Hello Emmanuel,
>
> Thanks a lot for your review. I’ve just posted version -02 that takes 
> your suggestions into account.
> More precisely:
>>
>> Having reviewing draft-ietf-tsvwg-fecframe-ext, I found this document 
>> quite clear, well-written and self-contained. I just have the 
>> following suggestions:
>>
>>
>> The authors argue that "/FECFRAME provides FEC protection for 
>> arbitrary packet flows over unreliable transports such as UDP/". 
>> RFC5348 proposes TFRC, an unreliable rate-based protocol which does 
>> not send data packets in a continuous manner at the same peak rate 
>> mimicking TCP average sending rate behavior or RFC4341 proposes DCCP 
>> CCID#2 congestion control which is an equivalent TCP window-based 
>> algorithm without retransmission.
>>
>> I reckon it is a good idea to dissociate transport layers operations 
>> from sliding encoding operations. But keeping in mind these both 
>> protocols (TFRC or DCCP/CCID#3 and DCCP/CCID#2) and considering the 
>> sentence "The data packets of continuous media flow(s) can be sent 
>> immediately, without delay." : "sent" is understood as "sent over the 
>> network" while this is not true depending on which unreliable 
>> transport protocol is used, so it should be "passed to the transport 
>> layer" as "sent over the network" only apply to UDP which does not 
>> schedule, pace or stop the sending. Actually some parts of this draft 
>> seem to consider that when source data or redundancy packets are 
>> built, they are simply sent over the network without delay. This is 
>> not always the case, so to be accurate I would suggest to correct by 
>> "passed to the transport layer" as correctly illustrated Fig. 1.
>
> VR: You’re right. In addition to congestion control, traffic shaping 
> may also delay packet transmissions (this is what
> we considered in our work where we considered a CBR link, re-using 
> 3GPP use-cases).
>
> NEW:
> The datapackets of continuous media flow(s) may be passed to the 
> transport layer immediately, without delay.
>
>
>> Same applies for : "since repair symbols can be generated and sent 
>> on-the-fly, »
>
> VR: Fixed.
>
> NEW:
> since repair symbols can be generated and passed to the
> transport layer on-the-fly, […]
>
>
>> "In practice FEC Source Packets can be sent as soon as available, 
>> without having to wait for FEC encoding to take place". This sounds 
>> like a priority scheduling between source data packets against repair 
>> packets. May be "Encoding operations should not influence data 
>> packets processing: FEC Source Packets should never be delayed and 
>> should always remain available to be passed to the transport layer. »
>
> VR: In fact there are several design options WRT to the question of 
> "when to send source and repair packets ».
> See: 
> https://datatracker.ietf.org/meeting/98/materials/slides-98-tsvwg-sessb-63-fecframe-drafts-00 (slide 
> 17).
> I don’t see good reasons to enter that type of detail in this 
> document, so I’ve opted to a more neutral sentence
> (using « may ») than what was there and what you propose (where 
> « should » is too strong).
>
> OLD:
> In practice FEC Source Packets can be sent as soon as
> available, without having to wait for FEC encoding to take place.
>
> NEW:
> In practice FEC Source Packets may be passed to the
> transport layer as soon as available, without having to wait for FEC
> encoding to take place.
>
>
>> "Protection amount" is defined but not used in this document. The 
>> definition suggests a kind of cross-layer with the transport protocol 
>> or a kind of application flow control. Should be either discussed nay 
>> suppressed.
>
> VR: Removed. It was inherited from RFC6363 definitions, but there 
> also, it was not explicitly used in the text.
>
>
>> EL
>
> Cheers,
>
>   Vincent


-- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel [phone] - Fax [phone]
Web : http://personnel.isae.fr/emmanuel-lochin/