Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt
Marie-Jose Montpetit <marie@mjmontpetit.com> Wed, 17 February 2021 17:47 UTC
Return-Path: <marie@mjmontpetit.com>
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 0ED4B3A1BFF for <nwcrg@ietfa.amsl.com>; Wed, 17 Feb 2021 09:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com
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 orNmKesP4HqU for <nwcrg@ietfa.amsl.com>; Wed, 17 Feb 2021 09:47:33 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0575A3A1BFE for <nwcrg@irtf.org>; Wed, 17 Feb 2021 09:47:32 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id r23so17405386ljh.1 for <nwcrg@irtf.org>; Wed, 17 Feb 2021 09:47:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=YDfNN7zbQKXDgZM0KyYA0AuzzycNKQjp5TCllWt3XfA=; b=1MmozT4+V3tIFYEIrT4NPWNuG1LQOs3gXqHjAbAnJfqAiwJ5eVw7Gt81U2DF5zZr7/ 2Iq4KMId5Sam2q6FFPsAGDdG60WJaPhi2yjj9kWXdEYPtW0UjkZOIT1qv3yrZN3Sdazx Nlsxas0LR4IfmJHqBeV7IaQ//ADVtbdcWthCYmryvu+yJrs6El8coQW4ZPnaqHU7NxZ5 KoFN1nPepPllnzMHurhaqMRppd5fna6BRoQurTZFiGf0AOdRNLMBdZ4RZGLQ1uhx4M8V WZWouolQDENT/yxx1oHlMIELSsnj2HWYPc0WbE+teFB7QlcbZ32IHsKT9jCdN65Fqh+e 9nYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=YDfNN7zbQKXDgZM0KyYA0AuzzycNKQjp5TCllWt3XfA=; b=niFCjHaTWZO4f5KceXnbD3fW2peHFU9+h+5lL3aHVwVj8uZnhKIOKVsIHG7QZnPiCc 39Q/n5apJgGrjeuSWhJtoCJUrUz3jCujTTPlXkyyXgKQTCc8x8NOqFrQnHTuYMWhfmyj YQa4q+iheIS1PBdjExXiNDUDIEyeySA22k8JImqYY1mVS2vKfG9TNfU2MikUdq/xr29O ZQNFsp92FSuZpTBqWw8ZJs8frzwaouSATSeQ2pi+kcc2+yHJKKGsTQZh3f75CcmlM0bY L/QXBvsMqdmzBg0utTkgzmDG/PudXacvpWZF3dS9TFeN/GV9wjhydEqqeXzAVklASt2e snpA==
X-Gm-Message-State: AOAM533Zc/DRnvFk6wIAVUYdWM9spB9rBWB9Et4CU66512iDw1Tn9e2m 63ap9DuZJv6OwZg2c1zkfcX9sZ52Xae2m9ybK7kDzQ==
X-Google-Smtp-Source: ABdhPJwWDOWzFOgFWf/xwzcnzd6xCO2FnSDWBrNt1bVkJasvKJu5A75uZsfyJMlA8NTj3veCalDxRCXJ61XoiKCAxvo=
X-Received: by 2002:a05:651c:102c:: with SMTP id w12mr239421ljm.432.1613584050673; Wed, 17 Feb 2021 09:47:30 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 12:47:30 -0500
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <1C77F32B-9B7F-4892-9E44-BF6CA7CA8595@inria.fr>
References: <161346137865.25827.8548083280026753510@ietfa.amsl.com> <F3B0A07CFD358240926B78A680E166FF29EC57C7@TW-MBX-P03.cnesnet.ad.cnes.fr> <1C77F32B-9B7F-4892-9E44-BF6CA7CA8595@inria.fr>
MIME-Version: 1.0
Date: Wed, 17 Feb 2021 12:47:30 -0500
Message-ID: <CAPjWiCSmzG1O7P9GghHUyKCZ0gdV9tntEHN2hLg_BbSpjd4dSw@mail.gmail.com>
To: Kuhn Nicolas <nicolas.kuhn@cnes.fr>
Cc: roca <vincent.roca@inria.fr>, iccrg IRTF list <iccrg@irtf.org>, "nwcrg@irtf.org" <nwcrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000027f36c05bb8bd0d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/y3yXmQGWjJQia_GZCRd54n3ajFA>
Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt
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: Wed, 17 Feb 2021 17:47:36 -0000
Ok so let me add to Vincent’s detailed comments with more generic ones some of the information exists - it may just need to be re-organized. - This is an IRTF document how is this relating to current research and where? - CC and NC are essentially two competing control loops - there is a lot of heritage on that topic (outside networking too) - what can NC/CC learn from that - any research questions? - My experience with NC is that the most gains are in low loss networks (far from network capacity) - where in fact CC protocols over react- is there research on appropriate metrics? - Most of the gain seems to be in last-mile/access networks - any other research? mjm Marie-José Montpetit, Ph.D. marie@mjmontpetit.com From: roca <vincent.roca@inria.fr> <vincent.roca@inria.fr> Reply: roca <vincent.roca@inria.fr> <vincent.roca@inria.fr> Date: February 17, 2021 at 5:52:20 AM To: Kuhn Nicolas <nicolas.kuhn@cnes.fr> <nicolas.kuhn@cnes.fr> Cc: roca <vincent.roca@inria.fr> <vincent.roca@inria.fr>, iccrg IRTF list <iccrg@irtf.org> <iccrg@irtf.org>, nwcrg@irtf.org <nwcrg@irtf.org> <nwcrg@irtf.org> Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt Dear authors, everybody, Thanks a lot for this significant revision of your I-D. Here are few comments, based on a quick review of the document. Cheers, Vincent ——— Generally speaking, this is a great document IMHO. Otherwise: ** Section 2.1: "The Forward Erasure Correction channel carries repair symbols (from the sender to the receiver) and potential information signaling which packets have been repaired (from the receiver to the sender). " Isn’t it a bit restrictive to say the feedback potentially carries information about repaired symbols only? We could imagine other types of information (loss rate prior and/or after decoding for instance). For instance, later, in section 4.3, you mention that: « The receiver may indicate to the sender the number of packets that have been received or recovered. » ** Section 2.2: "The document considers one application layer stream as input packets. The application layer may exploit several paths above both the FEC and transport layers; this case is not further described in the document. Confusion between « paths » and « stream ». Is it the same? Also, since this is a key point, could you just detail a bit more what are the implications of « several paths ». The various streams could be mapped on top of the same transport connection, or on top of different transport connection. Consequences are totally different. ** Section 2.3: This new section is important as it raises key questions. However the organisation of ideas could perhaps be a bit improved (several ideas are mixed I think). Last paragraph is okay however and contains the key messages in this section (perhaps swap last two sentences). ** Section 3.3: I don’t understand this part of the sentence: « Adapting the coding rate to the minimum required data rate of the application… » If I decide that the code rate adds a 5% overhead, then I don’t really care about the minimum required data rate of the app. It will increase the required data rate by 5%. My concern is more to know if this is compatible with the "available capacity given by the congestion control underneath" as said just before. I suspect it just needs to be reformulated. ** Section 3.6: I would say that partial reliability essentially impacts the type of FEC and type of codec you can use. If your codec does not enable a subset of the linear system to be inverted, but instead waits to have the perfect expected rank to invert and recover missing packets, you won’t achieve partial reliability. Partial reliability also impacts the way you use a block FEC: in that case, I’d say use small block sizes, so that you can solve one of them but not necessarily all of them… except that it will also lower the robustness in front of long loss periods. This is typically where sliding window codes do offer a key advantage. (see https://hal.inria.fr/hal-01571609v1/en/) ** Section 4: Are you sure that « the cost of capacity used to transmit source packets » is what you mean? I’d say: « to transmit repair packets » instead. ** Section 4.2: Is the assumption « If the FEC and CC channels are decoupled » meaningful when we talk about FEC within the transport? For me within means that they are both coupled in some way. ** Section 4.3: Mistake: « an increasing coding rate as a probe of the channel capacity » Increasing the coding rate reduces the amount of redundancy added. In fact I realize that coding rate is not defined. ** Section 5.4: I’d suggest talking about adjusting the code rate to what is actually needed instead of saying: « and tune the amount of useless repair symbols » ** Section 6 Open research questions While working on RFC 8681 on sliding window codes, we tried to find appropriate parameter derivation techniques. It turned out to be quite difficult. You can have a look at the discussion here: https://www.rfc-editor.org/rfc/rfc8681.html#name-possible-parameter-derivati Typo: ** section 3.2: add a final « s » to « retransmission » in: « may reduce the number of retransmission » Le 16 févr. 2021 à 08:45, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> a écrit : Dear all, We have worked on an updated version of the draft on interactions between congestion control and network coding. It will be presented in the NWCRG session of IETF110. Please let us know if you have any comments or views on the comment - there is still time for further updating the document before the cut-off for draft submission. Kind regards, Nicolas on the behalf of the authors -----Message d'origine----- De : nwcrg <nwcrg-bounces@irtf.org> De la part de internet-drafts@ietf.org Envoyé : mardi 16 février 2021 08:43 À : i-d-announce@ietf.org Cc : nwcrg@irtf.org Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Coding for efficient NetWork Communications Research Group RG of the IRTF. Title : Coding and congestion control in transport Authors : Nicolas Kuhn Emmanuel Lochin Francois Michel Michael Welzl Filename : draft-irtf-nwcrg-coding-and-congestion-05.txt Pages : 19 Date : 2021-02-15 Abstract: Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. Using FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications: FEC coding for tunnels is out-of-the scope of the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-05 https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ nwcrg mailing list nwcrg@irtf.org https://www.irtf.org/mailman/listinfo/nwcrg _______________________________________________ nwcrg mailing list nwcrg@irtf.org https://www.irtf.org/mailman/listinfo/nwcrg _______________________________________________ nwcrg mailing list nwcrg@irtf.org https://www.irtf.org/mailman/listinfo/nwcrg
- [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-c… internet-drafts
- [nwcrg] TR: I-D Action: draft-irtf-nwcrg-coding-a… Kuhn Nicolas
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… roca
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Marie-Jose Montpetit
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Michael Welzl
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Marie-Jose Montpetit
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Michael Welzl
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Emmanuel Lochin
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Marie-Jose Montpetit
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Kuhn Nicolas