Re: [tsvwg] WGLC on FECFRAME RLC FEC

[Gorry Fairhurst <[e-mail]>]

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