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

From: Emmanuel Lochin <[email-masked]>
Date: Tue, 1 May 2018 09:31:18 +0200

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
> [email-masked]
> 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 +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 1 May 2018 19:15:19 +0100

I have the read draft-ietf-tsvwg-fecframe-ext-01 during WGLC and have a 
few comments (as an individual),

Gorry

----
The following is stated:
/.   (e.g., because of a congested
    router, of a poor signal-to-noise ratio in a wireless network, or
    because the number of bit errors exceeds the correction capabilities
    of a low-layer error correcting code)./
- while this is true, it is probably wise to assert that most links 
supporting IP employ a CRC or other integrity check to verify this 
correctness, and that this is assumed. RFC3819 may be a suitable reference.
---
The terms RTP and DCCP are mentioned, but the base spec RFCs in each 
case are not cited.
---
/ This section discusses the protocol elements for the FEC Framework./
This section uses requirements language, and therefore the intro para 
needs to say how this applies. - It seems to me that this section does 
more than discuss, and some of it is actually to specify?

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 1 May 2018 19:15:55 +0100

I have the read draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and have 
the following comments (as an individual).
These comments are all on the text and the standards requirements being 
stated, they do not request changes to the method.
Gorry

---
/  They are meant to
    protect arbitrary media streams along the lines defined by FECFRAME
    extended to sliding window FEC codes./
- I think the word /meant/ reads a little weird. Rather as if they maybe 
do not do this. I suggest something like /They can provide protection 
to/ may be better?
---
Just to be sure, I would add /packet/ or something to /erasure recovery 
capabilities/ to be clear that this is not a bit-level FEC. Perhaps the 
first use of /FEC/ could also be better as /Application-Lyer FEC/ for 
the same purpose?
---
/in case of reliable file transfers/
could be clearer as:
/when used for reliable file transfers/
---
/Defining this block size requires to find an/
could be easier as:
/To define the block size, it is required to find an/
---
In 1.2 it states:
/This choice will impact all receivers./
- Maybe I misunderstand, but does it impact a receiver that sees no 
loss, because that could (in theory) act on the data as it arrives?
---
/are extremely efficient/
- This seems like a value judgment. I'd be content with saying 
/efficient/, but to say more I feel really needs a strong evidence that 
has consensus. RFCs must not be used to market techniques.
----
/latency close to zero/
- same comment, but perhaps this could be stated as /of the order of the 
time to transmit a packet/ our similar?
---
/waiting the end of the block for the first repair packet to arrive./
- perhaps clearer as:
/waiting for the first repair packet to arrive at the end of the block./
---
/sliding window codes achieve more easily a target/
- perhaps clearer as:
/sliding window codes can more achieve more efficiently achieve a target/
---
/The Sliding Window RLC FEC Scheme is designed so as to reduce the 
transmission overhead/
- perhaps clearer as:
/The Sliding Window RLC FEC Scheme is designed to reduce transmission 
overhead/
-> however I note the next phrases talk about /minimize packet 
overhead/, which could be seen as header bytes, is the distinction 
intended, then please explain - if not please use the same term.
----
/receiver to easily reconstruct/
- remove /easily/, or say they are /sufficient to allow a receiver to 
reconstruct/ or whatever, but avoid the value statement.
---
This strikes me as a little odd:
/In all situations, we MUST have:/
- If this is an actual RFC2119 requirement, then you need to state it 
terms of what the message contains. Although here I am unsure this is a 
protocol requirement, and if that is the case, it could be better to 
state the /method needs to ensure:/?
---
This seems an off phrase in a specification:
/     In practice they
       will usually be fixed, especially with multicast/broadcast
       transmissions. /
- could it instead be true to say something like /An implementation at a 
sender and receiver can fix these values/... or something like.
---
/Let us assume that the/ and /Let us also assume/
- seems rather like a paper, than a specification. Could this be 
reworded as /In the case when the code rate is .../etc.?
---
/It means that the source flow bitrate needs to be/
May be easier as:
/This requires the source flow bitrate to be/
---
Similarly:
  /It means that the transmission bitrate/ as /This requires the 
transmission bitrate/
-> but I have a question. of whether the /flow bitrate/ or /the 
transmission bitrate/ are actually different, and if not=, then why use 
two terms? Do we need either term as a /rate/ since this appears to be 
about volume of data and not rate?
---
/Finding the optimal value/
- I am unsure how you would define /optimal/ here, is it possible to say 
suitable/acceptable tradeoff or something like that without implying a 
need for optimal?
/and should be determined after simulations or field trials.  This is of 
course out of scope of this document.
/
- and finished like it is a report, rather than a specification. Is it 
therefore possible to simply say something like /An appropriate tradeoff 
needs to be determined depending on the use case..../
---
In section 3.2
/An ADU, coming from the application/
- is this at the sender? - just to be sure?
---
/ Indeed, a lost ADU recovered at a receiver must
    contain enough information to be assigned to the right application
    flow (UDP port numbers and IP addresses cannot be used to that
    purpose as they are not protected by FEC encoding).
/
- I could not parse this. Are the UDP port numbers and IP addresses not 
protected by the link integrity check and IP/transport checksum?
- If they were corrupted they would cause the packet to be delivered to 
another endpoint??? what is this about?
---
There seems to be no requirements language at all in section 3.1. Is 
this intended?
---
Section 3.2 speaks of /UDP/ datagrams. I am not sure this is correct, 
surely this applied to any type of datagram - DCCP, UDP, or anything 
else that could in the future carry FECFRAME.
---
/ Yet, any other
    implementation of the PRNG algorithm that matches the above
    validation criteria, like the ones detailed in [PM88], is
    appropriate.
/
- is that actually saying an implementation MAY use any PRNG algorithm 
that matches .../
---
/  The FEC Framework Configuration Information (or FFCI) includes
    information that MUST be communicated between the sender and
    receiver(s)./
- This confuses me about what are the specific requirements, can you 
please ensure that all the fields in this subsection carry an 
appropriate RFC2119 keyword (in upper case), to say which are OPTIONAL, 
REQUIRED, etc and what they MUST/MAY etc specify.
---
/A FEC Repair Packet can contain one or more repair symbols./
- is that a statement, or a permission? e.g.,
/A FEC Repair Packet MAY contain one or more repair symbols./

---
/integer carried the Density Threshold/
- is this /carries/
---
Is this discussion OK, or do you think we need to define the protocol 
actions using RFC2119 keywords:
/ The only constraint is to increment by
    1 the repair key for each of them, keeping the same ew_size source
    symbols, since only the first repair key will be carried in the
    Repair FEC Payload ID.  The FEC Repair Packet can then be sent./
- /sent/ probably should be /passed to the transport layer for 
transmission./
---
/ containing an ADU, can be passed to the application either
    immediately or after some time to guaranty an ordered delivery to the
    application. /
- This reads like it could be /MAY be passed/
---
/  received after this delay should not be passed to
    the application./
- I am unsure whether this needs to be read as /ought/ or /SHOULD/ could 
you use one of these instead of /should/?
---
In addition some standard transport comments that ought to be fine tuned:
/ Repair packets (symbols) are generated and sent on-the-fly/
- seems to perhaps be possibly to read as avoids CC, which it should 
not. Please be careful to indicate that packets are /passed to the 
transport layer for transmission/, if you think that these may be sent 
with higher priority than other messages, then please explicitly say this.
---
/where packets are sent with a fixed period/
- I think a word of caution here is needed with respect to CC. So this 
probably needs to be carefully worded, or at least say /are passed to 
the transport layer each fixed period/.
---
/The FEC Repair Packet can then be sent./
... maybe:
  /passed to the transport layer for transmission/
---

---

From: Vincent Roca <[email-masked]>
Date: Wed, 2 May 2018 11:24:34 +0200

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

---

From: Emmanuel Lochin <[email-masked]>
Date: Wed, 2 May 2018 12:27:05 +0200

Hi Vincent,

I'm fine with all your answers/corrections.

Cheers

EL

Le 02/05/2018 à 11:24, Vincent Roca a écrit :
>> 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.
>>
>> 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
> The datapackets of continuous media flow(s) may be passed to the 
> transport layer immediately, without delay.
>
>
>> on-the-fly, »
>> 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
>> 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 +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/

---

From: Vincent Roca <[email-masked]>
Date: Fri, 4 May 2018 16:30:27 +0200

Hello Gorry,

> I have the read draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and have the following comments (as an individual).
> These comments are all on the text and the standards requirements being stated, they do not request changes to the method.
> Gorry
> 

Thanks a lot for this very detailed review. It’s sometimes challenging and really helpful.
Here are my answers. Basically I agree with everything and updated the I-D accordingly.

I'll send the updated version of the I-D next week since we have spotted a few more things that need
to be fixed. More to come soon...

Cheers,

  Vincent and Belkacem

> - I think the word /meant/ reads a little weird. Rather as if they maybe do not do this. I suggest something like /They can provide protection to/ may be better?

VR: Fixed. 

NEW: 
They can protect arbitrary media streams...

> ---
> Just to be sure, I would add /packet/ or something to /erasure recovery capabilities/ to be clear that this is not a bit-level FEC. Perhaps the first use of /FEC/ could also be better as /Application-Lyer FEC/ for the same purpose?

VR: Very good point. We now mention "packet erasure recovery capabilities » in the abstract to avoid mis-understanding.
We also expend FEC acronym in the abstract (it was only the case in the title and Introduction).

> /when used for reliable file transfers/

VR: Done.

> /To define the block size, it is required to find an/

VR: Done.

> - Maybe I misunderstand, but does it impact a receiver that sees no loss, because that could (in theory) act on the data as it arrives?

VR: A perfect receiver will receive source data first and should not be impacted in any way. But that’s an exception. All the other receivers,
even those who experience a tiny (but not zero) loss rate, need to wait the same time on average: the time needed to receive repair packets
for that block, which directly depends on the block size chosen for the worst receiver. I’ve clarified the sentence.

OLD:
This choice will impact all receivers.

NEW:
This choice then impacts the
FEC-related latency of all receivers, even those experiencing a good
communication quality, since no FEC encoding can happen untill all
the source data of the block is available at the sender, which
directly depends on the block size.

> - This seems like a value judgment. I'd be content with saying /efficient/, but to say more I feel really needs a strong evidence that has consensus. RFCs must not be used to market techniques.

VR: Sure, you’re right. I propose the following sentence: 

OLD:
	These FEC Schemes are extremely efficient for instance with media that
	feature real-time constraints sent within a multicast/broadcast session.

NEW:
	These FEC Schemes, and more generally sliding window FEC codes, are recommended
	for instance with media that feature real-time constraints sent within a multicast/broadcast
	session [Roca17].

> ----
> /latency close to zero/
> - same comment, but perhaps this could be stated as /of the order of the time to transmit a packet/ our similar?

VR: Similarly I have changed for something more objective:

OLD:
	However the receivers experiencing a good to medium communication quality will observe
	a FEC-related latency close to zero [Roca17] since...

NEW:
	However the receivers experiencing a good to medium communication quality will observe
	a reduced FEC-related latency compared to block codes [Roca17] since...

> /waiting for the first repair packet to arrive at the end of the block./

VR: Done.

> /sliding window codes can more achieve more efficiently achieve a target/

VR: Done.

NEW: 
	… sliding window codes can more efficiently achieve a target transmission quality...

> ---
> /The Sliding Window RLC FEC Scheme is designed so as to reduce the transmission overhead/
> - perhaps clearer as:
> /The Sliding Window RLC FEC Scheme is designed to reduce transmission overhead/
> -> however I note the next phrases talk about /minimize packet overhead/, which could be seen as header bytes, is the distinction intended, then please explain - if not please use the same term.

VR: Yes, the term « overhead » is misleading here. 

NEW:
	The Sliding Window RLC FEC Scheme is designed to limit the packet header overhead.

> - remove /easily/, or say they are /sufficient to allow a receiver to reconstruct/ or whatever, but avoid the value statement.

VR: Done.

> - If this is an actual RFC2119 requirement, then you need to state it terms of what the message contains. Although here I am unsure this is a protocol requirement, and if that is the case, it could be better to state the /method needs to ensure:/?

VR: Since RFC2119 recommends to use these terms sparingly, I’ve changed for:

OLD:
	In all situations, we MUST have:
	         ew_size <= ew_max_size

NEW:
	At session start, the encoding window will probably be small and then progressively increase until it reaches its maximum value. 
	At any time: 
		ew_size <= ew_max_size

> - could it instead be true to say something like /An implementation at a sender and receiver can fix these values/... or something like.

VR: I have clarified this part.

NEW:
      An implementation
      at a sender can fix the E parameter and communicate it as part of
      the FEC Scheme-Specific Information (Section 4.1.1.2).  There is
      no need to communicate the cr parameter per see (it's not required
      to process a repair packet at a receiver).  This cr parameter can
      be fixed, however, in specific use-cases and in particular with
      unicast transmissions in presence of a feedback mechanism that
      estimates the communication quality (out-of-scope of FECFRAME),
      the code rate may be adjusted dynamically.

> - seems rather like a paper, than a specification. Could this be reworded as /In the case when the code rate is .../etc.?

VR: Reworded.

> /This requires the source flow bitrate to be/

VR: Reworded.

> ---
> Similarly:
> /It means that the transmission bitrate/ as /This requires the transmission bitrate/
> -> but I have a question. of whether the /flow bitrate/ or /the transmission bitrate/ are actually different, and if not=, then why use two terms? Do we need either term as a /rate/ since this appears to be about volume of data and not rate?

VR: We are dealing here with bitrates in bits/s, not volume. We use source (resp. repair) flow bitrates and transmission bitrate to denote
the bitrate at the FECFRAME sender output.
There was a additional term, « input bitrate », that I have replaced with source flow bitrate.

> - I am unsure how you would define /optimal/ here, is it possible to say suitable/acceptable tradeoff or something like that without implying a need for optimal?
> /and should be determined after simulations or field trials.  This is of course out of scope of this document.
> /
> - and finished like it is a report, rather than a specification. Is it therefore possible to simply say something like /An appropriate tradeoff needs to be determined depending on the use case…./

VR: Removed « optimal » as suggested, and tried to have it less like a report.

> - is this at the sender? - just to be sure?

VR: Yes, added « At a sender ».

> - I could not parse this. Are the UDP port numbers and IP addresses not protected by the link integrity check and IP/transport checksum?
> - If they were corrupted they would cause the packet to be delivered to another endpoint??? what is this about?

VR: I admit this is a complex paragraph (the technic is from FECFRAME, it’s not something added here for the pleasure).
It’s not a matter of corruption. I’ve tried to improve the explanation. Here it is:

NEW:
   At a sender, an ADU coming from the application cannot directly be
   mapped to source symbols.  When multiple source flows (e.g., media
   streams) are mapped onto the same FECFRAME instance, each flow is
   assigned its own Flow ID value (see below).  At a sender, this
   identifier is prepended to each ADU before FEC encoding.  This way,
   FEC decoding at a receiver also recovers this Flow ID and a recovered
   ADU can be assigned to the right source flow (note that UDP port
   numbers and IP addresses cannot be used to that purpose as they are
   not recovered during FEC decoding).

> ---
> There seems to be no requirements language at all in section 3.1. Is this intended?

VR: I guess you mean 3.2. No, it’s not intentional. I’ve added a MUST: 

NEW:
	For each incoming ADU, an ADUI MUST created as follows.

> ---
> Section 3.2 speaks of /UDP/ datagrams. I am not sure this is correct, surely this applied to any type of datagram - DCCP, UDP, or anything else that could in the future carry FECFRAME.

VR: Right! Fixed.

> - is that actually saying an implementation MAY use any PRNG algorithm that matches …/

VR: Any implementation of the multiplicative congruential algorithm with the constants defined, that
additionally matches the validation criteria could be used.
Look at http://www.firstpr.com.au/dsp/rand31/ <http://www.firstpr.com.au/dsp/rand31/> to get an idea of how prolific the topic is. It’s impressive.

That being said, I’ve removed this sentence to avoid confusion since I already explain that the PM88
algorithm MUST be used. No need to say more.

> - This confuses me about what are the specific requirements, can you please ensure that all the fields in this subsection carry an appropriate RFC2119 keyword (in upper case), to say which are OPTIONAL, REQUIRED, etc and what they MUST/MAY etc specify.

VR: You’re right, the current sentence can be confusing.
We follow here FECFRAME requirements (RFC 6363 section 5.6) that explains what MUST be
detailed in a FEC Scheme specification in terms of signalling (which we actually provide).
I’ve changed text to avoid this confusion (no MUST any more).

NEW:

4.1.1.  FEC Framework Configuration Information

   Following the guidelines of [RFC6363], section 5.6, this section
   provides the FEC Framework Configuration Information (or FFCI).  This
   FCCI needs to be shared (e.g., using SDP) between the FECFRAME sender
   and receiver instances in order to synchronize them.  It includes a
   FEC Encoding ID, mandatory for any FEC Scheme specification, plus
   scheme-specific elements.

4.1.1.1.  FEC Encoding ID
[…]

And the same applies to section 5.1.1. (but without any explanatory text).

> /A FEC Repair Packet MAY contain one or more repair symbols./

VR: Good catch. That’s a technical possibility. Changed for MAY as suggested.

VR: Fixed.

> ---
> Is this discussion OK, or do you think we need to define the protocol actions using RFC2119 keywords:

VR: You’re right.

NEW:
   In that case the repair key for each of
   them MUST be incremented by 1, keeping…

> - /sent/ probably should be /passed to the transport layer for transmission./

VR: Yes, as in the FECFRAME I-D. Done. There’s also another instance where « sent » has been replaced.

> - This reads like it could be /MAY be passed/

VR: Done. I’ll try to be more careful with RFC2119 keywords in the future.

> - I am unsure whether this needs to be read as /ought/ or /SHOULD/ could you use one of these instead of /should/?

VR: it’s a matter of deciding what component is responsible of detecting late ADUs. 
All things considered, I’d prefer to relax the requirement to do that within FECFRAME. It’s an implementation decision,
we just explain (section 3.1.  Parameters Derivation) how to reduce the risk to lead to late decodings.

NEW:
   With real-time flows, a lost ADU that is decoded after the maximum
   latency or an ADU received after this delay has no value to the
   application.  This raises the question of deciding whether or not an
   ADU is late.  This decision MAY be taken within the FECFRAME receiver
   (e.g., using the decoding window, see Section 3.1) or within the
   application (e.g., using RTP timestamps within the ADU).  Deciding
   which option to follow and whether or not to pass all ADUs, including
   those assumed late, to the application are operational decisions that
   depend on the application and are therefore out of scope of this
   document.

> - seems to perhaps be possibly to read as avoids CC, which it should not. Please be careful to indicate that packets are /passed to the transport layer for transmission/, if you think that these may be sent with higher priority than other messages, then please explicitly say this.

VR: Changed.

NEW:
   Repair packets (symbols) are generated on-the-fly, computing a random linear
   combination of the source symbols present in the current encoding window, and
   passed to the transport layer.

> - I think a word of caution here is needed with respect to CC. So this probably needs to be carefully worded, or at least say /are passed to the transport layer each fixed period/.

VR: the CBR assumption was needed to derive parameters, but I agree it gives the
impression CC is bypassed (in fact in our 3GPP use-case there’s no CC).
At the light of our discussions (and also with Belkacem) I’m not satisfied with 
	section 3.1.  Parameters Derivation
and will come back with a brand new version.

> .... maybe:

VR: Done.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 04 May 2018 16:05:00 +0100

Thanks these corrections seem like what I expected, thanks for doing them.

Maybe you chekc that youcheck that change /untill/until/.

Best wishes,
Gorry

On 04/05/2018, 15:30, Vincent Roca wrote:
> Hello Gorry,
>
>> I have the read draft-ietf-tsvwg-rlc-fec-scheme-02 during WGLC and 
>> have the following comments (as an individual).
>> These comments are all on the text and the standards requirements 
>> being stated, they do not request changes to the method.
>> Gorry
>>
>
>> - I think the word /meant/ reads a little weird. Rather as if they 
>> maybe do not do this. I suggest something like /They can provide 
>> protection to/ may be better?
>
> VR: Fixed.
>
> NEW:
>
>> Just to be sure, I would add /packet/ or something to /erasure 
>> recovery capabilities/ to be clear that this is not a bit-level FEC. 
>> Perhaps the first use of /FEC/ could also be better as 
>> /Application-Lyer FEC/ for the same purpose?
>
> VR: Very good point. We now mention "packet erasure recovery 
> capabilities » in the abstract to avoid mis-understanding.
> VR: A perfect receiver will receive source data first and should not 
> be impacted in any way. But that’s an exception. All the other receivers,
> even those who experience a tiny (but not zero) loss rate, need to 
> wait the same time on average: the time needed to receive repair packets
> for that block, which directly depends on the block size chosen for 
> the worst receiver. I’ve clarified the sentence.
>
> OLD:
>
>> /efficient/, but to say more I feel really needs a strong evidence 
>> that has consensus. RFCs must not be used to market techniques.
>
>> - same comment, but perhaps this could be stated as /of the order of 
>> the time to transmit a packet/ our similar?
>
>> terms of what the message contains. Although here I am unsure this is 
>> a protocol requirement, and if that is the case, it could be better 
>> to state the /method needs to ensure:/?
>
> At session start, the encoding window will probably be small and then 
> progressively increase until it reaches its maximum value.
> At any time:
> ew_size <= ew_max_size
>
>
>> ---
>> - could it instead be true to say something like /An implementation 
>> at a sender and receiver can fix these values/... or something like.
>
>> transmission bitrate/ are actually different, and if not=, then why 
>> use two terms? Do we need either term as a /rate/ since this appears 
>> to be about volume of data and not rate?
>
> VR: We are dealing here with bitrates in bits/s, not volume. We use 
> source (resp. repair) flow bitrates and transmission bitrate to denote
>> - I am unsure how you would define /optimal/ here, is it possible to 
>> say suitable/acceptable tradeoff or something like that without 
>> implying a need for optimal?
>> - and finished like it is a report, rather than a specification. Is 
>> it therefore possible to simply say something like /An appropriate 
>> tradeoff needs to be determined depending on the use case…./
>
>> - I could not parse this. Are the UDP port numbers and IP addresses 
>> not protected by the link integrity check and IP/transport checksum?
>> - If they were corrupted they would cause the packet to be delivered 
>> to another endpoint??? what is this about?
>
> VR: I admit this is a complex paragraph (the technic is from FECFRAME, 
> it’s not something added here for the pleasure).
> Look at http://www.firstpr.com.au/dsp/rand31/ to get an idea of how 
> prolific the topic is. It’s impressive.
>
>> appropriate RFC2119 keyword (in upper case), to say which are 
>> OPTIONAL, REQUIRED, etc and what they MUST/MAY etc specify.
>
>> - I am unsure whether this needs to be read as /ought/ or /SHOULD/ 
>> could you use one of these instead of /should/?
>
> All things considered, I’d prefer to relax the requirement to do that 
> within FECFRAME. It’s an implementation decision,
>> transport layer for transmission/, if you think that these may be 
>> sent with higher priority than other messages, then please explicitly 
>> say this.
>
> VR: Changed.
>
> NEW:
>> - I think a word of caution here is needed with respect to CC. So 
>> this probably needs to be carefully worded, or at least say /are 
>> passed to the transport layer each fixed period/.
>

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 15 May 2018 21:42:32 -0400

On 4/17/2018 12:30 AM, Wesley Eddy wrote:
> ...

Many thanks for the couple of technical reviews that were submitted 
(Emmanuel and Gorry), and to Vincent for quickly updating the drafts in 
response.

Since this is work for standards track, I think we really need to get a 
bit more feedback though.

In order to get more reviews, and give people time to look at the 
updated drafts, so will plan to keep the WGLC open for a couple more 
weeks in order to give more time for reviews. *Please provide comments 
on the updated documents by 5/29.*

Thanks in advance.

---

From: Jonathan DETCHART <[email-masked]>
Date: Thu, 17 May 2018 10:16:05 +0200

I read the draft-ietf-tsvwg-rlc-fec-scheme.

2 typo :

- p3, $1.2. : "the Sliding Window Random Linear Codes (RLC) over either 
Finite Field GF(2) or GF(8)". Should it be GF(2^8)?

- p22, $7 : "Lincencing" -> "Licencing"

As the document "introduces two fully-specified FEC Schemes". 
Considering the field GF(2^8), it can be implemented in several ways, 
depending on the irreducible polynomial that is used and the 
implementation (xor-based representation or polynomial representation 
with lookup tables or not). All the implementations are not compatible.

So, how do the encoder and decoder agree on the field and the 
implementation used to be compatible? Do they exchange some parameters? 
Should the document propose a default configuration for that?

I suggest the document propose a default specification for galois field 
arithmetic: it should give the irreducible polynomial used (like in the 
rfc 5510), and the implementation to use. For gf(2^8), a lookup table 
implementation (with optional SIMD vector instructions) seems to be the 
best on most devices : 
http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html

Jonathan DETCHART

On 16/05/2018 03:42, Wesley Eddy wrote:
> (Emmanuel and Gorry), and to Vincent for quickly updating the drafts 
> in response.
>
> Since this is work for standards track, I think we really need to get 
> a bit more feedback though.
>

---

From: Vincent Roca <[email-masked]>
Date: Thu, 17 May 2018 13:07:27 +0200

Hi Jonathan,

Excellent comments! We need to clarify the Finite Field used, I agree.
Here is a new section to address this comment:

NEW:

3.6.  Finite Fields Operations

   The two RLC FEC Schemes specified in this document reuse the Finite
   Fields defined in [RFC5510], section 8.1.  More specifically, the
   elements of the field GF(2^^m) are represented by polynomials with
   binary coefficients (i.e., over GF(2)) and degree lower or equal to
   m-1.  The addition between two elements is defined as the addition of
   binary polynomials in GF(2), which is equivalent to a bitwise XOR
   operation on the binary representation of these elements.

   With GF(2^^8), multiplication between two elements is the
   multiplication modulo a given irreducible polynomial of degree 8.
   The following irreducible polynomial MUST be used for GF(2^^8):

      x^^8 + x^^4 + x^^3 + x^^2 + 1

   With GF(2), multiplication corresponds to a logical AND operation.

The reference to (the excellent) Plank’s research report is already in version -03.
The two typos are fixed.

We’ll submit a new -04 version with the above corrections plus an
improved section 3.1.  Possible Parameter Derivations. More to come soon...

Cheers,

  Vincent and Belkacem

> Le 17 mai 2018 à 10:16, Jonathan DETCHART <[email-masked]> a écrit :
> 
> - p3, $1.2. : "the Sliding Window Random Linear Codes (RLC) over either Finite Field GF(2) or GF(8)". Should it be GF(2^8)?
> As the document "introduces two fully-specified FEC Schemes". Considering the field GF(2^8), it can be implemented in several ways, depending on the irreducible polynomial that is used and the implementation (xor-based representation or polynomial representation with lookup tables or not). All the implementations are not compatible.
> So, how do the encoder and decoder agree on the field and the implementation used to be compatible? Do they exchange some parameters? Should the document propose a default configuration for that?
> 
> I suggest the document propose a default specification for galois field arithmetic: it should give the irreducible polynomial used (like in the rfc 5510), and the implementation to use. For gf(2^8), a lookup table implementation (with optional SIMD vector instructions) seems to be the best on most devices : http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html <http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html>
> Jonathan DETCHART
>>> 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/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/> 
>>> 
>>> (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/> 
>>> 
>>> ...
>>> 
>> 
>> 
>> Many thanks for the couple of technical reviews that were submitted (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in response.
>> 
>> Since this is work for standards track, I think we really need to get a bit more feedback though.
>> 
>> In order to get more reviews, and give people time to look at the updated drafts, so will plan to keep the WGLC open for a couple more weeks in order to give more time for reviews.  Please provide comments on the updated documents by 5/29.
>> 
>> Thanks in advance.
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>