Re: [nwcrg] Tetrys draft

[Emmanuel Lochin <[e-mail]>]

Le 29/09/2021 à 15:11, Nicolas Kuhn a écrit :
> Dear all,
>
> I think it is important for the NWCRG to publish examples of coding 
> mechanisms and thus support the adoption of the document.
>

Hi Nicolas,

Thank you for your time in reviewing this draft. An updated version 
should be released soon. In waiting, please find our answers below :


> Some comments below.
>
> ====
> "This update is done in so that any
>    source packets coming from an input flow are included in the encoding
>    window as long as it is not acknowledged or the encoding window did
>    not reach a size limit."
> => This is not clear to me. Is the following clearer and correct ? I 
> am not sure what happens when the encoding window reaches its size limit.
> "The update of the size of the encoding window is necessary for any
>    source packets coming from an input flow to be included in the encoding
>    window. Source packets are stored in the encoding window as long as 
> they are not acknowledged.
>   If the encoding window reaches its size limit, source packets are 
> (dropped?)."

True, we modified the text as follows :

The main innovation of the Tetrys protocol is in the generation of coded 
packets from an elastic encoding window. This window is filled by any 
source packets coming from an input flow and is periodically updated 
with the receiver's feedbacks. These feedbacks return to the sender the 
highest sequence number received or rebuilt, which allows to flush the 
corresponding source packets stored in the window. The size of this 
window can be fixed or dynamically updated. If the window is full, 
incoming source packets are dropped. As a matter of fact, its limit 
should be correctly sized. Finally, Tetrys allows to deal with losses on 
both the forward and return paths and in particular, is resilient to 
acknowledgment losses.

>
> ====
> "This mechanism allows for losses on both the
>    forward and return paths and in particular, is resilient to
>    acknowledgment losses."
> => ?
> "This mechanism recovers source packets that have been lost wih the 
> FEC tunnel on both the
>    forward and return paths and in particular, is resilient to
>    acknowledgment losses."

Also corrected (see above)

>
> ===
> " It is
>    aligned with the FECFRAME terminology conjointly with recent
>    activities in the Network Coding Research Group."
> => I think this section should refer to RFC8406
> Also, it may be worth checking some of the vocabulary that is not 
> consistent (e.g. encoding coefficients vs coding coefficients)

Corrected thanks
>
> ===
> "       -- Editor's note: The architecture used in this document should be
>       aligned with the future NC Architecture document [NWCRG-ARCH]. --"
> => Because NWCRG ARCHI may not be published, this should be cleaned.

Corrected

>
> ===
> "
>                        Figure 1: Tetrys Architecture
> "
> => I think this section should refer to the NC-CC draft that could be 
> published soon.

Also done

>
> ===
> "    o  Congestion control management (if appropriate);
>
>          -- Editor's note: must be discussed --
> "
> => Such as discussed in the NC-CC draft, if the congestion control 
> management is not discussed, it could result in an important 
> unfairness. In particulier, research question 3 and 4 should be 
> discussed ( or at least recalled here) :
> /   Research question 3 : "Should we quantify the harm that a coded flow
>    would induce on a non-coded flow ? How can this be reduced while
>    still benefiting from advantages brought by FEC ?"
>
>    Research question 4 : "If transport and FEC senders are collocated
>    and close to the client, and FEC is applied only on the last mile,
>    e.g. to ignore losses on a noisy wireless link, would this raise
>    fairness issues ?"/

In the updated version, although Tetrys supports CC, it remains an 
option. We thus refer to draft-irtf-nwcrg-coding-and-congestion for 
questions related to NC and CC.

>
> ===
> "    o  Congestion control flag (C): 2 bits.  C=0 indicates the Congestion
>       Control Information (CCI) field is 0 bits in length. C=1
>       indicates the CCI field is 32 bits in length.  C=2 indicates the
>       CCI field is 64 bits in length.  C=3 indicates the CCI field is 96
>       bits in length.
>
>          -- Editor's note: version number and congestion control to be
>          discussed --
> "
> => I am not sure to assess the content of the CCI. It may be worth 
> detailing some more.

We are currently discussing this point indeed.


>
> ===
> "
>    PLR: packet loss ratio expressed as a percentage.
> "
> => Is it the PLR after decoding ? Does the receiver indicate the 
> amount of recovered packets so that the server can adapt the coding rate ?

This value is only used in the case of dynamic encoding or for 
statistical purpose. The choice of calculation is left to the 
appreciation of the developer but should be the PLR seen before decoding.
We complete in the draft.

Thanks again Nicolas !

>
>
>
> On Tue, Sep 28, 2021 at 10:54 PM Marie-Jose Montpetit 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     We had on our charter to promote a number of network codes with
>     informational RFCs. The Tetrys draft is in a state that is close
>     to a final version. However it was never accepted as a RG draft.
>
>     This email is to ask if anyone opposes declaring Tetrys a nwcrg draft.
>
>     The team (in cc. and which includes Vincent Roca so I will deal
>     with this alone) plans to produce a reviewable version in the next
>     month and we could start the the review process ahead of IETF 112
>     with a plan to finalize the process soon after.
>
>     I will contact potential reviewers personally to expedite the process.
>
>     Thanks everyone!
>
>     mjm
>
>     Marie-José Montpetit, Ph.D.
>     [e-mail] <mailto:[e-mail]>
>
>
>     _______________________________________________
>     nwcrg mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.irtf.org/mailman/listinfo/nwcrg
>     <https://www.irtf.org/mailman/listinfo/nwcrg>
>

-- 
Emmanuel LOCHIN
ENAC - Ecole Nationale de l'Aviation Civile
7, avenue Edouard Belin CS 54005, 31055 Toulouse Cedex 4 France
http://www.enac.fr
https://elochin.github.io/