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

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

Thanks Emmanuel. Cedric: please confirm your changes were made and you
agree with the new version.

We can then proceed.

mjm (w/o Vincent who is a co-author)

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



From: Emmanuel LOCHIN <[e-mail]> <[e-mail]>
Reply: Emmanuel LOCHIN <[e-mail]> <[e-mail]>
Date: April 24, 2022 at 6:29:40 AM
To: Cedric Adjih <[e-mail]> <[e-mail]>
Cc: [e-mail]
<[e-mail]>
<[e-mail]>, nwcrg <[e-mail]>
<[e-mail]>
Subject:  RE: Review of draft-irtf-nwcrg-tetrys-01.txt

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=