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

[Vincent Roca <[e-mail]>]

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