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

[Dirk Kutscher <[e-mail]>]

Dear Jonathan and co-authors,

thanks for the update, the new security considerations, and the explanation regarding the relationship to transport protocol.

This addresses my comments. I'll confirm that on the IRSG list as well, as soon as someone share the new version there.

Best regards,
Dirk




On 17 Nov 2022, at 17:04, Jonathan Detchart wrote:

> Dear all,
>
> First, thank you very much Dirk, for your review. We integrated all your editorial comments.
>
> About your technical comments:
>
> 1. relation to and expectations from transport protocols:
>
> As said in this draft, the objective of this document is to describe the baseline of the Tetrys protocol, allowing communications between a Tetrys encoder and a Tetrys decoder. Tetrys is thus an AL-FEC-like protocol and the draft is limited to this description.
> The 6th section is an attempt to discuss research issues as this draft comes from an IRTF working group. This section is not to consider as a part of the protocol implementation detail. This section is dedicated to discuss research issue when Tetrys is deployed either as a standalone protocol or within an existing protocol, and either above, within or below the transport layer. There are different research questions related to each of these scenarios that should be investigated for future protocol improvements that are detailed in this section.
>
> Of course, open to discuss about that.
>
>
> 2. security considerations :
>
> We completely rewrote the Security Considerations part to be more explicit about threats and expectations on secure transport.
>
>
> All changes can be found in the new version of the draft : https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-tetrys-04
>
>
> Jonathan DETCHART
>
> Le 10/16/2022 à 1:53 PM, Marie-Jose Montpetit a écrit :
>> 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]> <mailto:[e-mail]>
>> Reply: Dirk Kutscher <[e-mail]> <mailto:[e-mail]>
>> Date: October 15, 2022 at 3:57:15 AM
>> To: Amy Vezza <[e-mail]> <mailto:[e-mail]>
>> Cc: Colin Perkins <[e-mail]> <mailto:[e-mail]> , Internet Research Steering Group <[e-mail]> <mailto:[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).
>>>
>>>       o 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."
>>>       o 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..."?
>>>       o 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."
>>>       o 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"
>>>
>>>       o 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."
>>>
>>>       o "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."
>>>
>>>       o "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."
>>>
>>>       o 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."
>>>       o 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
>>>
>>
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/nwcrg