Re: [nwcrg] RG Last Call for "Coding and congestion control in transport"

roca <vincent.roca@inria.fr> Fri, 11 June 2021 14:46 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F223A463A for <nwcrg@ietfa.amsl.com>; Fri, 11 Jun 2021 07:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDvF7CxydHwU for <nwcrg@ietfa.amsl.com>; Fri, 11 Jun 2021 07:45:58 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8AB3A463C for <nwcrg@irtf.org>; Fri, 11 Jun 2021 07:45:57 -0700 (PDT)
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A/eDnrasruTJc8orJrbZKz2Xy7skDW9V00zEX?= =?us-ascii?q?/kB9WHVpmwKj5riTdZUgpGTJYVMqMk3I9urwXJVoLUmskKKdpLNhX4tKPzOHhI?= =?us-ascii?q?LLFvAE0WKK+VSJcBEWtNQttpuIGJIObuEYY2IK9PrS0U2VNesBqeP3ipxARt2z?= =?us-ascii?q?856ud2xXgm1bgTuRwzz1c3FLeA=3D=3D?=
X-IronPort-AV: E=Sophos;i="5.83,265,1616454000"; d="scan'208,217";a="513076616"
Received: from xbn44-4_migr-88-165-27-50.fbx.proxad.net (HELO smtpclient.apple) ([88.165.27.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2021 16:45:55 +0200
From: roca <vincent.roca@inria.fr>
Message-Id: <FF3C4150-056A-49A4-A5E6-A8C7B0829BEE@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F580703F-A9CA-4896-96BF-B6D07051F36B"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Fri, 11 Jun 2021 16:45:54 +0200
In-Reply-To: <DEF1E3BB-27C8-4F38-8BEA-BB2E12477063@inria.fr>
Cc: roca <vincent.roca@inria.fr>, Marie-Jose Montpetit <marie@mjmontpetit.com>, nwcrg@irtf.org
To: draft-irtf-nwcrg-coding-and-congestion.authors@ietf.org
References: <DEF1E3BB-27C8-4F38-8BEA-BB2E12477063@inria.fr>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/GyLzLwMyqCx6xJK1QporI3iUDnw>
Subject: Re: [nwcrg] RG Last Call for "Coding and congestion control in transport"
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2021 14:46:03 -0000

Dear authors,

I’ve read your updated I-D which I find in pretty good shape. 
I only have a few minor comments below.

For me, the I-D is ready for IRSG review, once these comments are fixed.
However I’d like to have another opinion on the topic.

Sorry for the delay in reading it (RGLC finished 11 days ago).

Cheers,   Vincent


Clarification:

** Section 2.3:
- 1st paragraph:
The use of multipath can indeed be associated to the case where there are multiple application streams, to split different streams to different paths, but not necessarily. The way it's written suggests me multipath is useless unless there are several application streams.
I'm pretty sure this is not what you mean.
- fig 4 and 5: could you write in the figures what is in scope and what is not. It's hard to follow from the text.
- What are the motivations for considering or not each possibility? It's not clear to me after reading this section.


** Section 9, security considerations:
What about manipulating feedback signals in order to compromize FEC rate adaptation? These feedback packets could be dropped or modified by an attacker. This is a way to trigger a DoS that specifically uses the technics described in this document that should be discussed briefly IMHO.


Minor comments:

** suggestion: "recovered" instead of "repaired" in 2.1. (repaired suggests there could be an error I think).

** fig 1: I'm a bit surprised by the arrows:
   |      |           source and/or  ---->|      |
   |      | -----    repair symbols  ---->|      |

Why not the following:
   |      |           source and/or       |      |
   |      | -----    repair symbols  ---->|      |
or even:
   |      | -----     source and/or  ---->|      |
   |      | -----    repair symbols  ---->|      |




> Le 10 mai 2021 à 10:48, Vincent Roca <vincent.roca@inria.fr> a écrit :
> 
> Dear all,
> 
> Following the recent update of the I-D (thank you!), we would like to officially start a RG Last Call for:
> 	"Coding and congestion control in transport"
> 	https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
> 
> The call will end on Monday May 31st (3 weeks).
> 
> Please read it and provide feedback on the mailing list. Thanks in advance.
> 
> Regards,
> 
>     Marie-Jose and Vincent