Re: [nwcrg] [LOOPS] BOF co-chairs thinking on LOOPS next steps

Carsten Bormann <cabo@tzi.org> Tue, 30 July 2019 15:01 UTC

Return-Path: <cabo@tzi.org>
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 ECFBF120130 for <nwcrg@ietfa.amsl.com>; Tue, 30 Jul 2019 08:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 PHcfQ2XpjWCG for <nwcrg@ietfa.amsl.com>; Tue, 30 Jul 2019 08:01:30 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A21C1200F8 for <nwcrg@irtf.org>; Tue, 30 Jul 2019 08:01:30 -0700 (PDT)
Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45yfs41sChzyf5; Tue, 30 Jul 2019 17:01:28 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAPjWiCSG9Z+etdp3e9r0Rr4R=Zm_EbjZm03WnTon9nqNfpRX=g@mail.gmail.com>
Date: Tue, 30 Jul 2019 17:01:27 +0200
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, "nwcrg@irtf.org" <nwcrg@irtf.org>, Suresh Krishnan <suresh@kaloom.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, loops@ietf.org
X-Mao-Original-Outgoing-Id: 586191627.7237149-79f44496709c5aa7790c100c12d7c2bf
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AED146F-0A68-41EA-8218-D25F1572A129@tzi.org>
References: <CAKKJt-eRGJe+9PtEC7xgFz+HA0zsr_sR0NUgKRmJ-P5Q3XBg-A@mail.gmail.com> <CAPjWiCSbPioTHkYBpX73qxzO=H1sJDZpCMCKzBKoU4rZLLhwMQ@mail.gmail.com> <E6659E42-D6D7-4033-B4D6-9305823063D2@tzi.org> <CAKKJt-c24RdPyZRoK-B6fXuN0xABUsU=p7Y6UFwAcENfjE3oOQ@mail.gmail.com> <A4576796-AACA-4BE1-9EF8-9422E1BAB9F3@kuehlewind.net> <CAKKJt-dCeJVhofU8eO=TXu6CVez5g9ZTdLnp206gx6X3YTx9tA@mail.gmail.com> <CAPjWiCSG9Z+etdp3e9r0Rr4R=Zm_EbjZm03WnTon9nqNfpRX=g@mail.gmail.com>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/y8eI526ywt4ORmee96rky8R0Oh0>
Subject: Re: [nwcrg] [LOOPS] BOF co-chairs thinking on LOOPS next steps
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: Tue, 30 Jul 2019 15:01:33 -0000

Hi Marie-José,

> <mjm> There are FEC mechanisms to adapt coding dynamically based on acknowledgments for example. In the QUICK implementation we will have flag a RECOVERED packet that could be used to adapt the coding rate. Other implementations or code-specific protocols are also available.

Right.  So a LOOPS variant will still need to be developed.

>> 	• 
>> How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
> <mjm> Well the use of FEC (or not) is a design decision.  Of course you need the code (and the libraries). And then the decision will be based on known link condition, goodput, expected performance, type of traffic (video, time sensitive etc.). And finding a tunnel and PEPs if you need to. And it can depend on path statistics and not being end to end. I am not sure you could standardize that decision.

What can be decided unilaterally does not need to be standardized.
Information that needs to be collected in cooperation between both ends to enable this decision (“measurement information”) may need to be standardized.

In any case, the LOOPS stance to setting up the channel is a “controller model”, i.e. we don’t plan to have negotiation or some such in the protocol, but expect a controller to set up both ends in a coordinated way.  This is probably the biggest item that needs to be added to enable host-to-node mode, as the host is less likely to be involved in that controller model (even though it could be, that part would then also need to be standardized).

>> How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")?
> <mjm> Of course in a congested network doing nothing is probably best. Again there is a lot of work on the interaction of coding and congestion control.

Right, which would need to be worked out into a protocol plus at least some basic best current practice algorithms for LOOPS.

> <mjm> Not everyone knows the things but there has been a lot of work in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work was done in a research group not a working group. But real implementations exist in famous “networks”. 

Great.  So let’s start to identify those documents that are nearly ready to be used and fit well.  E.g., for NWCRG, I’m aware of:

  "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)
  Schemes for FECFRAME", Vincent Roca, Belkacem Teibi, 2019-06-18,
  <draft-ietf-tsvwg-rlc-fec-scheme-16.txt>


and possibly (I’m not sure yet LOOPS will be a straightforward application of FECFRAME):

  "Forward Error Correction (FEC) Framework Extension to Sliding Window
  Codes", Vincent Roca, Ali Begen, 2019-01-11,
  <draft-ietf-tsvwg-fecframe-ext-08.txt>

> 
> <mjm> Since most of your questions are about erasure coding (coding for packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG?

In a certain way, very much so.  Now LOOPS is intended to have a retransmission mode, too, which probably would go beyond standard fare of NWCRG.  I’m also not sure that the finer points of measurement that are needed (bilaterally) to enable really good LOOPS implementations (mostly unilaterally) are covered in NWCRG, and I’m also not sure about congestion feedback.  But I wouldn’t mind to call the thing NWCWG, as long as we get to ship the retransmission mode first.

Grüße, Carsten