Re: [nwcrg] Review of draft-irtf-nwcrg-tetrys-01.txt

[Emmanuel LOCHIN <[e-mail]>]

Dear Cedric, all,

Thank you so much for this in-depth review of our draft. We have addressed all your comments point by point in the recently pushed updated version.
Conjointly to this submission, you will find below our answers inline and how we treated them inside the document.
All our answers begin with [TETRYS] to ease the reading.
See below ...

________________________________
De : Cedric Adjih <[e-mail]>
Envoyé : jeudi 24 février 2022 10:16
À : nwcrg <[e-mail]>
Cc : Colin Perkins <[e-mail]>; Vincent Roca <[e-mail]>; Emmanuel LOCHIN <[e-mail]>; DETCHART Jonathan <[e-mail]>; jerome.lacan <[e-mail]>; Marie-Jose Montpetit <[e-mail]>
Objet : Review of draft-irtf-nwcrg-tetrys-01.txt

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


[TETRYS] As this main comment is a global summary of all points raised below, we propose to jump directly to the general comments below and answer them point by point. Note that these answers aims at completing what is already updated in the last submitted version.


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.

[TETRYS] First, these fields lay on RFC3451 and their purpose is to provide to developers an access to congestion control information, if needed, when implementing their own protocol. Actually, all these points deal with the congestion control interaction which is not the purpose of this draft. The current draft does not aim at identifying interaction issues with the transport layer, knowing these issues are also discussed in https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ However, this interaction is further discussed Section 6.1 as a research issue.


  *   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).

[TETRYS] Simply because we are considering C calls (e.g. read()), where a 32 bits size might improve the performance.


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

[TETRYS] At least, the current proposal works. There is certainly a better way to do it, but this might not be trivial.
SACK is indeed a proven and efficient method and the other formats are for vector encodings which limit the amount of information needed to represent a linear combination. However, we believe this discussion would have more interest in the context of an IETF standard, and not within an informative contribution, as this is the case here.


  *   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.

[TETRYS] Definitely, we changed the notation in the last submitted version.

  *   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.

[TETRYS] Agree, we used the same approach than in RFC8681 Section  3.7.1 and added RFC5510. This part has been completely modified.


More detailed comments:


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


[TETRYS] We think we understand your concern, as the sentence pointed out may be a bit fuzzy. We changed to emphasize that the design of Tetrys protocol detailed in this document is _completed_ by a record of the experience gained by the authors while developing and testing in real conditions the Tetrys protocol and in particular, several research issues are discussed in Section 6 following our own experience and observations.


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


[TETRYS] All these operations are further detailed in Section 4.


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


[TETRYS] Once again, we believe this discussion would be more useful in the context of an IETF standard as the coding rate management should be designed by the developer. However and as we are in the context of an informative draft, we discuss potential issues concerning the coding rate, in particular when interacting with a congestion controlled transport layer in Sections 6.1 and 6.2. Note also thta we refer to [I-D.irtf-nwcrg-coding-and-congestion], which is another draft written by some of the authors that further elaborate on this problem.


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


[TETRYS] They can be non-contiguous but ordered (e.g., the window might contain symbols : {s10, s11, s12, s14, s15} where s13 is missing). However, non-contiguous IDs prevent the possibility to "compress" the source ID list in the encoding vector.


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


[TETRYS] True. Similarly to TCP, a full protocol should implement ISO Transport Service from RFC2126 and particularly protocol exchange messages such as connection establishment, connection release, buffer size negotiation (similarly to TCP flow control), ... The encoding window must be bounded and this limit should be negotiated between both end-points for instance, at the beginning of the connection.


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


[TETRYS] Agree, we change the notation (see PKT_TYPE_SOURCE, PKT_TYPE_CODED, PKT_TYPE_WND_UPT, ...)


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


[TETRYS] One possible other solution could be to use Connection IDs as in QUIC RFC9000. Their main objective is to prevent wrong endpoint delivery of packets due to changes in addressing at lower protocol layers (UDP, IP). Basically each connection handles a set of connection identifiers able to identify the connection independently of the IP address. Connection IDs are independently selected by endpoints and each endpoint selects the connection IDs used by its peer.


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


[TETRYS] As previously mentioned above this has been updated in the novel submitted version (see lines 704 to 741) starting from :
 704       The two RLC FEC schemes specified in this document
 705       reuse the Finite Fields defined in [RFC5510], Section 8.1.  More
 706       specifically, the elements of the field GF(2^(m)) are represented
 707       by polynomials with binary coefficients (i.e., over GF(2))


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


[TETRYS] Four examples have been added with the resulting fields to clarify.


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


[TETRYS] The field NB_IDS represents the number of IDs stored in the encoding vector, and not the number of IDs in the linear combination. Ex: the linear combination R1 = S1 + S2 + S3 + S4 can generate an encoding vector with NB_IDS = 2 because we only need to store 1 and 4 as an edge block of source IDs.


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


[TETRYS] see answer just above.


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


[TETRYS] We see, there is a missing definition : max(L) represents here the maximum of the elements of L. This definition has been added to clarify.


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


[TETRYS] The whole paragraph has been changed (acknowledgment packet becomes window update packet) and the term has obviously been updated when it appears elsewhere in the draft. We have explained both use-cases of these packets (received or dropped). The change starts from :

867 5.4.  Window Update Packet Format
868
869    A Tetrys Decoder MAY send back to another building block some Window
870    Update packets.  They contain information about what the packets
871    received, decoded or dropped, and other information such as a packet
(...)

963    the recovery of the following packets.  The "First Source Symbol" is
964    included in this bit vector.  A bit equal to 1 at the i-th position
965    means that this window update packet removes the Source Symbol of ID
966    equal to "First Source Symbol ID" + i from the encoding window


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


[TETRYS]  Done. For example, 2.5 % will be stored as floor(2.5 * 256/100) = 6. Conversely, if 6 is the stored value, the corresponding packet loss ratio expressed as a percentage is 6*100/256 = 2.34 %.


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"


[TETRYS] All of these minors comments have been considered. In particular the problem of capitalization of the terms.


Many thanks  Cedric !


The authors


best regards,
-- Cedric

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

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.
[e-mail]<mailto:[e-mail]>



_______________________________________________
nwcrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/nwcrg