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

[Emmanuel Lochin <[e-mail]>]

Dear all,

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.

Same applies for : "since repair symbols can be generated and sent 
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."

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

EL



On 17/04/2018 06:30, Wesley Eddy wrote:
> (on behalf of all three TSVWG chairs)
>
> This email is to start a TSVWG working group last call on the sliding 
> window FECFRAME extensions, and random linear code FEC scheme drafts:
>
> (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/
>
> (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/
>
> We would like to collect any comments within 3 weeks (until around May 
> 8).  We believe all of the comments raised in the past have been 
> addressed, and that these are ready to go for Proposed Standard.
>
> I'm cross-posting this to the Network Coding RG, since there are some 
> experts that may not be on TSVWG, but we'd like any comments to go to 
> the TSVWG list please.
>
> Thanks in advance.
>
>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg

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