Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt
Michael Welzl <michawe@ifi.uio.no> Thu, 18 February 2021 12:34 UTC
Return-Path: <michawe@ifi.uio.no>
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 9374B3A1188; Thu, 18 Feb 2021 04:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 XROnqnCBw0jX; Thu, 18 Feb 2021 04:34:17 -0800 (PST)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 388E13A1078; Thu, 18 Feb 2021 04:34:15 -0800 (PST)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1lCiVW-0003rL-7s; Thu, 18 Feb 2021 13:34:10 +0100
Received: from ti0182q160-3425.bb.online.no ([62.249.177.137] helo=[192.168.1.7]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1lCiVT-0002ub-NN; Thu, 18 Feb 2021 13:34:10 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <10191065-AEEE-4BE8-A481-3A7C1F1621FA@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC58B3F1-182D-4AAF-A6C7-1CE9317B2596"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 18 Feb 2021 13:34:02 +0100
In-Reply-To: <CAPjWiCSmzG1O7P9GghHUyKCZ0gdV9tntEHN2hLg_BbSpjd4dSw@mail.gmail.com>
Cc: Kuhn Nicolas <nicolas.kuhn@cnes.fr>, roca <vincent.roca@inria.fr>, iccrg IRTF list <iccrg@irtf.org>, "nwcrg@irtf.org" <nwcrg@irtf.org>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
References: <161346137865.25827.8548083280026753510@ietfa.amsl.com> <F3B0A07CFD358240926B78A680E166FF29EC57C7@TW-MBX-P03.cnesnet.ad.cnes.fr> <1C77F32B-9B7F-4892-9E44-BF6CA7CA8595@inria.fr> <CAPjWiCSmzG1O7P9GghHUyKCZ0gdV9tntEHN2hLg_BbSpjd4dSw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 62.249.177.137 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.249.177.137; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.013, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 44827E1A3C9BC961FEFDB14BB0EB269C9D8E6702
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/arGp85WqpYFWqOj3BfXQGfnoXeg>
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: Thu, 18 Feb 2021 12:34:22 -0000
Hi all, Interesting questions, thanks! A bit difficult to answer, too… I hope my co-authors have ideas ;-) I’m intrigued by one in particular, down below: > On Feb 17, 2021, at 6:47 PM, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote: > > 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? *low* loss, far from network capacity? Why would a CC mechanism over-react? When it’s far from the capacity, there’s nothing to react upon… did you mean that they are too cautious and flows terminate before even reaching the capacity limit? I can imagine this being an interesting scenario for coding indeed, but I’d like to understand if this is what you meant. Cheers, Michael > - Most of the gain seems to be in last-mile/access networks - any other research? > > mjm > > Marie-José Montpetit, Ph.D. > marie@mjmontpetit.com <mailto:marie@mjmontpetit.com> > > > > From: roca <vincent.roca@inria.fr> <mailto:vincent.roca@inria.fr> > Reply: roca <vincent.roca@inria.fr> <mailto:vincent.roca@inria.fr> > Date: February 17, 2021 at 5:52:20 AM > To: Kuhn Nicolas <nicolas.kuhn@cnes.fr> <mailto:nicolas.kuhn@cnes.fr> > Cc: roca <vincent.roca@inria.fr> <mailto:vincent.roca@inria.fr>, iccrg IRTF list <iccrg@irtf.org> <mailto:iccrg@irtf.org>, nwcrg@irtf.org <mailto:nwcrg@irtf.org> <nwcrg@irtf.org> <mailto: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/ <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 <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 <mailto: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 <mailto:nwcrg-bounces@irtf.org>> De la part de internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> >>> Envoyé : mardi 16 février 2021 08:43 >>> À : i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> >>> Cc : nwcrg@irtf.org <mailto: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/ <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://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-05> >>> https://datatracker.ietf.org/doc/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 <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 <http://tools.ietf.org/>. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> >>> >>> >>> _______________________________________________ >>> nwcrg mailing list >>> nwcrg@irtf.org <mailto:nwcrg@irtf.org> >>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg> >>> >>> _______________________________________________ >>> nwcrg mailing list >>> nwcrg@irtf.org <mailto:nwcrg@irtf.org> >>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg> >> >> _______________________________________________ >> nwcrg mailing list >> nwcrg@irtf.org <mailto:nwcrg@irtf.org> >> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg> > _______________________________________________ > nwcrg mailing list > nwcrg@irtf.org <mailto:nwcrg@irtf.org> > https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
- [nwcrg] TR: I-D Action: draft-irtf-nwcrg-coding-a… Kuhn Nicolas
- [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-c… internet-drafts
- 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