[nwcrg] Fwd: Re: [irsg] IRSG review request draft-irtf-nwcrg-tetrys-03

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

Dear Tetrys authors:

please find enclosed the result of Dirk’s review of the Tetrys draft and
please address them so we can move forward. It’s getting to the end!

And thank you Dirk for this careful review.

mjm

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



From: Dirk Kutscher <[e-mail]> <[e-mail]>
Reply: Dirk Kutscher <[e-mail]> <[e-mail]>
Date: October 15, 2022 at 3:57:15 AM
To: Amy Vezza <[e-mail]> <[e-mail]>
Cc: Colin Perkins <[e-mail]> <[e-mail]>, Internet
Research Steering Group <[e-mail]> <[e-mail]>
Subject:  Re: [irsg] IRSG review request draft-irtf-nwcrg-tetrys-03

Hi all,

here is my review:
Review of draft-irtf-nwcrg-tetrys-03

Dirk Kutscher ([e-mail])
General Comments

   - good and useful specification for publication as an Experimental RFC
   - I have a few technical comments – see below
   - quite a few editorial issues – not sure the RFC Editor will fix all
   of them – see below
   - *suggestion:* produce one more update before passing this on

Technical Comments

   -

   *discuss:* I am missing some text at the beginning that explains
   the relation to and expectations from transport protocols. Later, in
   6.2. for example, you allude to UDP, multipath transport etc. IMO,
   the document could be improved by providing this notion of
   independence from *specific* transport protocols, while explaining
   the expectations (feedback channel, for example).
   - If you agree, you could provide a few examples as well. Side note:
      I could imagine Tetrys being applicable to ICN as well (but this
      may be intricate to describe here).
   -

   *discuss:* The Security Considerations seem a little weak: "As an
   application layer end-to-end protocol, security considerations of
   Tetrys should also be comparable to those of HTTP/2 with TLS." I
   think you should describe threats and expectations on secure
   transport more explicitly.

Definitions, Notations and Abbreviations

   - *Verify:* "Source Symbol: a symbol that has to be transmitted between
   the ingress and egress of the network."
      - I would avoid languages such as "has to" that could imply
      implementation requirements ("MUST") etc. Can't you just say "a
      symbol that is transmitted..."?
      - If you mean "must" then consider writing "MUST".

Editorial Comments General comments

   - some interpunctuation errors that the RFC editor might be able to fix
   - some language issues (not sure I caught all of them)

Abstract

   - *Revise:* "This document is a record of the experience gained by the
   authors while developing and testing in real conditions the Tetrys
   protocol."
      - For example: "This document is a record of the experience gained
   by the authors while developing and testing the Tetrys protocol in
   realistic conditions."

Introduction

   -

   *Consider revising:* 2nd paragraph: "While the use of network codes is
   fairly recent"
   - For example: "While network codes have seen some deployment fairly
      recently..."
   -

   *Revise:* 3rd paragraph: "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 encoding window."
   - "This window is filled by any Source Packets coming from an input

   flow and is periodically updated with receiver feedback. These
   feedback messages provide the sender sender with information about
   the highest sequence number received or rebuilt, which can enable
   flushing the corresponding Source Packets stored in the encoding
   window."
   -

   *Revise:* 3rd paragraph: "All these operations are further detailed in
   Section Section 4."
   - "All these operations are further detailed in Section 4."
   -

   *Revise* last paragraph: "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."
   - The description of the design of the Tetrys protocol in this

   document is complemented by a record of the experience gained by
   the authors while developing and testing the Tetrys protocol in
   realistic conditions."

Definitions, Notations and Abbreviations

   - *Consider revising:* "Feedback Packet: a Feedback Packet is a
   packet containing information about the decoded or received
   Source Symbols. It MAY also bring additional information about
   the Packet Error Rate or the number of various packets in the
   receiver decoding window."
   * "... It MAY also contain additional information..."

5.1.1 Header extensions

   - The items in the list at the look odd: " Header Extension Type (HET):
   8 bits The type of the Header Extension."

6 Research Issues

   - *Revise:* "All these situations raise manyfold research questions
   to come up with a complete protocol solution, that we briefly
   discuss hereafter."
      - For example: "There are different research questions related to
      each of these scenarios that should be investigated for future
      protocol improvements. We summarize them in the following
      subsections."

Best regards,
Dirk

--

PGP fingerprint: 2D08387A195CD207853E1892278F4979A077CA8C

On 13 Oct 2022, at 11:31, Dirk Kutscher wrote:

Hi Amy, Colin, and all,

I can offer reviewing this one.

Best regards,
Dirk

--

PGP fingerprint: 2D08387A195CD207853E1892278F4979A077CA8C

On 12 Oct 2022, at 22:20, Amy Vezza wrote:

Hi all!

We still need at least one IRSG Member to volunteer to review
draft-irtf-nwcrg-tetrys. From the document abstract:

This document describes Tetrys, an On-The-Fly Network Coding (NC)
protocol that can be used to transport delay and loss-sensitive data
over a lossy network. Tetrys may recover from erasures within an
RTT-independent delay, thanks to the transmission of Coded Packets.
This document is a record of the experience gained by the authors
while developing and testing in real conditions the Tetrys protocol.

This document is a product of the Coding for Efficient Network
Communications Research Group (NWCRG). It conforms to the NWCRG
taxonomy[RFC8406].

The document itself looks to be about 20 pages long. Please send email to
the group if you’re able to perform such a review, and indicate the
approximate time-frame by which you’ll be able to complete it.

Thank you so much!

Amy

Amy Vezza
[e-mail]

On Oct 5, 2022, at 6:11 PM, Colin Perkins <[e-mail]> wrote:

IRSG members,

The NWCRG Research Group has requested that draft-irtf-nwcrg-tetrys-03 be
considered for publication as an IRTF RFC. To progress this draft, we now
need at least one IRSG member to volunteer to provide a detailed review of
the draft, as follows:

The purpose of the IRSG review is to ensure consistent editorial and
technical quality for IRTF publications. IRSG review is not a deep
technical review. (This should take place within the RG.) At least one IRSG
member other than the chair of the RG bringing the work forth must review
the document and the RG’s editorial process.

IRSG reviewers should look for clear, cogent, and consistent writing. An
important aspect of the review is to gain a critical reading from reviewers
who are not subject matter experts and, in the process, assure the document
will be accessible to those beyond the authoring research group. Also,
reviewers should assess whether sufficient editorial and technical review
has been conducted and the requirements for publication described in RFC
5743 have been met. Finally, reviewers should check that appropriate
citations to related research literature have been made.

Reviews should be written to be public. Review comments should be sent to
the IRSG and RG mailing lists and entered into the tracker. All IRSG review
comments must be addressed. However, the RG need not accept every comment.
It is the responsibility of the shepherd to understand the comments and
ensure that the RG considers them including adequate dialog between the
reviewer and the author and/or RG. Reviews and their resolution should be
entered into the tracker by the document shepherd.

The IRSG review often results in the document being revised. Once the
reviewer(s), authors, and shepherd have converged on review comments, the
shepherd starts the IRSG Poll on whether the document should be published.

Please respond to this message if you’re able to perform such a review, and
indicate the approximate time-frame by which you’ll be able to complete it.
The document shepherd write-up is available at
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-tetrys/shepherdwriteup/.

Thanks!
Colin