Re: [nwcrg] Tetrys draft

[Marie-Jose Montpetit <[e-mail]>]

Thank you Nicolas - for the ok and the review :)

mjm

Marie-José Montpetit, Ph.D.
[e-mail]



From: Nicolas Kuhn <[e-mail]>
<[e-mail]>
Reply: Nicolas Kuhn <[e-mail]>
<[e-mail]>
Date: September 29, 2021 at 9:11:39 AM
To: Marie-Jose Montpetit <[e-mail]> <[e-mail]>
Cc: nwcrg <[e-mail]> <[e-mail]>, Vincent Roca
<[e-mail]> <[e-mail]>, Jérôme Lacan
<[e-mail]> <[e-mail]>, Jonathan
DETCHART <[e-mail]>
<[e-mail]>, Emmanuel Lochin
<[e-mail]> <[e-mail]>
Subject:  Re: [nwcrg] Tetrys draft

Dear all,

I think it is important for the NWCRG to publish examples of coding
mechanisms and thus support the adoption of the document.

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?)."

====
"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."

===
" 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)

===
"       -- 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.

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

===
"    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 ?"*

===
"    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.

===
"
   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 ?



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
>