Re: [nwcrg] Tetrys draft

[Pierre Ugo Tournoux <[e-mail]>]

Dear all,

I support this draft and the idea to provide a document that helps in
implementing an on-the-fly coding protocol. As we are looking forward to
implementing Tetrys on IoT devices, we do appreciate the fact that the
common packet header size could be reduced to a minimum of 32 bits. In the
context of LPWAN it might have been profitable to reduce the symbol id to
16 or 8bit though.

We may start this implementation effort as soon as the RFC is stabilized.

Thanks to the NWCRG for pursuing the tetrys' standardisation.

Pierre

Le dim. 3 oct. 2021 à 12:14, Emmanuel Lochin <[e-mail]> a
écrit :

> 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]> 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]
>>
>>
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail]
>> 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 Francehttp://www.enac.frhttps://elochin.github.io/
>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg
>