Subject: [nwcrg] RGLC (a last “last call”) on draft-irtf-nwcrg-tetrys

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 9 Feb 2022 07:59:10 -0500

Dear all:

after comments on the previous version the draft Tetrys has been updated
and the new version (01) is available here:

https://datatracker.ietf.org/doc/draft-irtf-nwcrg-tetrys/

I would like to start a 2-weeks last call ending on Feb. 23 before moving
to the next steps.

Please read it and provide feedback on the mailing list.
Thanks in advance!

Marie-José (as only co-chair since Vincent is an author)

Marie-José Montpetit, Ph.D.
[email-masked]

---

From: Cedric Adjih <[email-masked]>
Date: Thu, 24 Feb 2022 10:16:24 +0100 (CET)

Dear authors, dear participants of the nwcrg, 

Here is a review of the document draft-irtf-nwcrg-tetrys-01.txt 

(the line numbering is obtained from "cat -n draft-irtf-nwcrg-tetrys-01.txt"). 

Globally, the document still needs some editing, but the content is already in good shape. 

    * Main comments: 

One main comment is that the document describes parts of a protocol (that had been already implemented and experimented), but there is not a clear boundary on which parts are described and which parts are not. 

About half of the draft is focusing on the packet format (Section 5), but it might be useful to provide/move some information on the semantics of the protocol in an earlier part(s). This is true especially because some of the semantics are implied/only presented in passing while detailing the bits of the packet format protocol, and on the other hand, some of the important high-level information and considerations appear in Section 6. Maybe there is some room for instance in Sections 3 or 4 to give an overview of some of the semantics and close some of the gaps between packet format et research considerations: such as rules or examples for repair/redundant packets generation, elastic window management with respect to feedback, etc. 

Generally, it is not immediately clear what are the objective and the content of the document as it presents itself as: 

25 This document is a record of the experience gained by the authors 

26 while developing and testing in real conditions the Tetrys protocol. 

In particular, the current document would allow the parsing or generation of well-formed Tetrys packets by a third party, but would not necessarily allow developing an interoperable implementation (or even a full standalone implementation), especially since some parts are missing considering the feedback management, and window management - but it might also not be an objective of the document? 

The authors might consider whether the document is intended to include a small primer on how an implement a sender/receiver scenario in open-loop transmissions (no feedback) with the packet format they have; or even a sender/receiver scenario with some example of feedback management (and in this case does the protocol always attempt to recover all packets?) 

General comments on the packet format: 

I am not an expert on packet formats, and also am not sure whether the document aims to document a packet format that already works for implementation (hence is already self-contained), or if the intent is to define a good basis for Tetrys-like protocol. In any case, I would have the following comments: 

    * Some parts are describing specific exceptions that much not further documented/used in the current draft: in particular the congestion control information (lines 420-424 / 458-464), the transport section identifier (lines 426-428 / 466-477), and the section Header Extension (Section 5.1.1), that are either optional or have alternate formats. It might be simpler for instance to provide a single, generic "Type-Length-Value" format for all options (e.g. RFC 8609 Section 3), or at least use the generic Header Extension format for the CCI and TSI options as well. 
    * Some of the efforts are spent to align the various fields on a 32 bits boundary: it is fine, although it is not clear how much of this is necessary (given that only source/coded symbol IDs are 32 bits long). 
    * Among the methods to specify lists of Source Symbol IDs, one is used in one direction (compressed list, Section 5.3.1.1), another is used in the other direction (SACK bitmap, lines 887-905); might this be streamlined? 
    * It can be helpful to give symbolic names to predefined constant values of message fields (such as packet types) as if there were an IANA registries section. 

Better (more precise) definitions could be given, be referring to other documents. Notably the algebraic description of finite fields, and the coefficient computation (lines 706-721), which had been also specified elsewhere, for instance RFC 5510 and elsewhere. 

More detailed comments: 

. lines 25-26, lines 156-157 -> maybe improve the description of the scope of the draft? 

. lines 132-140 - the authors might further elaborate on the window, feedback, and rate management in a later section. 

. lines 306-312 - the "Window Management Building Block" seems to be akin to an algorithm; also are the coding rate management and congestion management in this picture? 

. lines 331-33 - do the source symbols in the Elastic Encoding Window have contiguous source symbol ID? 

. line 348-352 - generally, what Tetrys does when using feedback is not well defined in the draft, but here in particular when the encoding window size is overflowing, probably both sides (encoder/decoder) have to take some undefined actions. 

. line 454 - "source packets (0)" -> something like "PT_SOURCE_SYMBOL"? (that would make lines 588, 644 clearer) 

. lines 466-477 - it is maybe not necessary to specify that "IP + TSI" uniquely define a session, as it may depend on the way Tetrys is integrated with the other layers. For instance in case of multiple interfaces, maybe it is acceptable to consider different source IP addresses as in the same session? 

. lines 706-721 - maybe this part deserves its own paragraph (or subsection). This should specify main details: the finite field (e.g. GF(256), GF(16)), the unambiguous encoding of its elements (for instance bit-order of the polynomial coefficients), the unambiguous choice for alpha "root of the primitive polynomial" (not sure what is its representation), etc. Also a bonus hint on why the choice of "Vandermonde" form could be nice (and why the modulo). Maybe refer to other RFCs? 

. lines 735, 741, 761, 765, 766, 778 - it is unclear what is an "edge block", hence the difference between "compressed list of the source symbol IDs" and "compressed edge blocks of source symbol IDs" is a bit unclear. In general, Section 5.3.1.1 and 5.3.1.2 help, but some more examples of (all?) possible encoding vector formats might help. 

. line 752-756 - since each source symbol ID should be associated with a coefficient and conversely, it is not clear why there is both one <NB_COEFS> field and one <NB_IDS> field. 

. line 777 - what do "boundaries" mean? Also, observe that the fields <FIRST_SOURCE_ID> and <NB_IDS> should completely define the first, last source symbol ID and their number. Maybe check there is no duplicate information. 

. lines 789-820 - on the description of the compression method hints that the "edge blocks" might be intervals. The compression method seems to be equivalent to a run-length encoding of the bitmap of source symbol IDs; (it could be nice to have hints about when it is expected to perform well). As it is written, check if it is "ceil(log2(max(L))" or "ceil(log2(max(L+1))". Also conversely, the "0" value might not be acceptable, so it can be excluded, and maybe it is already correct, and 'b' should be "ceil(log2(max(L+1-1))" ; if "0" is acceptable, the associated semantics should be specified. 

. Line 822-905 - as mentioned previously, the semantics associated with acknowledgements is not defined. In addition, line 852 is defining a count "since the beginning of the session", rather than in the recent past, along with a number of unused (not already used) coded symbols. It is unclear what this last number means (line 874-875) does not really clarify it. In addition, if the packet loss is such that some source symbol IDs happen to be never retrieved at the decoder, it is unclear what these quantities are representing. 

. Line 880-885, the PLR is expressed in %, then encoded in a byte: should the receiver be able to represent 100% PLR? And it can alternately be specified as "floor(PLR*255)" ? (or *256) 

Possible typos/unclear parts/language: 

. line 146 "system contraints" -> does this means "coefficient overhead"? 

. line 150 "an algorithm or a function" -> a "predefined method" ? 

. line 152-153 "along with a transmission" -> "at the time of packet generation"? 

. consistency: lines 201,204 "Tetrys Encoding Building Block", lines 262-263 "Tetrys Encoder"/"Tetrys Decoder", line 306 "Tetrys Building Block", lines 809-824 "Tetrys Decoding Building Block" 

. line 230 "a function or an algorithm" -> redundant? 

. lines 233-234, the definition of code rate is ok but short (consider RFC 5510 or RFC 8406) 

. line 358: "encoding building Block" -> consistent capitalization 

. line 371-372: "A classical matrix inversion" -> maybe, more precisely, "Gaussian eliminination" 

. line 379: "Figure 2 )." -> "Figure 2)." 

. line 532,539,545 - "8 bits The length" etc. -> punctuation missing? 

. line 604 - "(see Section 5.3.1 )." -> "(see Section 5.3.1)." 

. line 702 - "CCCGI" -> "CCGI" 

. line 706 - maybe explain in the notation part that "a^^b denotes a raised to the power b." as in RFC 6816. 

. line 708, 715 - "coded-symbol_id" -> "coded_symbol_id" or "<coded symbol id>" and around the same lines "alpha^(" -> "alpha^^(" ? 

. line 723, 744, 747 - the name of the fields/flags "Store the Source symbol IDs (I)", "Store the coefficients (C)", "Having source symbols with variable size (V)", etc. could be improved. E.g "Source Symbol ID Format (I)", "Variable Size Encoding (V)" or something, etc. And, again, maybe with the IANA-registry-style name for the possible values. In general, the naming of the fields of Section 5 can be checked. 

. line 744: "1 bit to _know_" -> "specify"/"indicate" 

. lines 774, 776, 780 - "identifer" -> "identifier" 

. capitalization consistency can be checked (e.g "Source symbol ID" vs "source symbol ID" vs "Source Symbol ID", more generally for all the terms in Section 2) and also w.r.t title capitalization, e.g. line 789 

. line 913: "manifold" 

best regards, 
-- Cedric 

De: "Marie-Jose Montpetit" <[email-masked]> 
À: "nwcrg" <[email-masked]>, "Colin Perkins" <[email-masked]> 
Cc: "Vincent Roca" <[email-masked]>, "Emmanuel Lochin" <[email-masked]>, "DETCHART Jonathan" <[email-masked]>, "jerome lacan" <[email-masked]> 
Envoyé: Mercredi 9 Février 2022 13:59:10 
Objet: [nwcrg] RGLC (a last “last call”) on draft-irtf-nwcrg-tetrys 

BQ_BEGIN

Dear all: 

after comments on the previous version the draft Tetrys has been updated and the new version (01) is available here: 

[ https://datatracker.ietf.org/doc/draft-irtf-nwcrg-tetrys/ | https://datatracker.ietf.org/doc/draft-irtf-nwcrg-tetrys/ ] 

I would like to start a 2-weeks last call ending on Feb. 23 before moving to the next steps. 

Marie-José Montpetit, Ph.D. 
[ mailto:[email-masked] | [email-masked] ] 

_______________________________________________ 
nwcrg mailing list 
[email-masked] 
https://www.irtf.org/mailman/listinfo/nwcrg 
BQ_END