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

Colin Perkins <csp@csperkins.org> Wed, 31 July 2019 14:14 UTC

Return-Path: <csp@csperkins.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 ACAD1120077; Wed, 31 Jul 2019 07:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 X40L-9cRSKnd; Wed, 31 Jul 2019 07:14:51 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 C4CB112006D; Wed, 31 Jul 2019 07:14:50 -0700 (PDT)
Received: from [130.209.157.54] (port=50825 helo=glaroam2-179-133.wireless.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <csp@csperkins.org>) id 1hspNM-0003fg-Ix; Wed, 31 Jul 2019 15:14:48 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <591523D9-D5C0-4FAB-A835-7472B2907544@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7498BA51-6778-4399-85E0-FC48ECF9CA7E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 31 Jul 2019 15:14:42 +0100
In-Reply-To: <CAKKJt-cJVXLDtfAQ3uk2JENVtKTR5TVRsHQzHznAxGpaSOXJRw@mail.gmail.com>
Cc: Marie-Jose Montpetit <marie@mjmontpetit.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "nwcrg@irtf.org" <nwcrg@irtf.org>, loops@ietf.org, Mirja Kuehlewind <ietf@kuehlewind.net>, Carsten Bormann <cabo@tzi.org>, Suresh Krishnan <suresh@kaloom.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
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> <CAKKJt-dkMcmLvLjs=e=6nHH97R_jBrjJj23UE-1Tbv7-aTDxdw@mail.gmail.com> <2342D6E9-FF90-4D51-9647-0F7ABDA47268@csperkins.org> <CAKKJt-cJVXLDtfAQ3uk2JENVtKTR5TVRsHQzHznAxGpaSOXJRw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/RfSpo5cOjHzXNxQVJqAD0uwec78>
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: Wed, 31 Jul 2019 14:14:55 -0000

Agree - thanks, Spencer.
Colin



> On 31 Jul 2019, at 14:18, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Colin,
> 
> On Wed, Jul 31, 2019, 07:36 Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>> wrote:
>> On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> wrote:
>> 
>> I'm going to be replying to two or three e-mail in this thread, so I'll try to be coherent over my replies .... 
>> 
>> On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit <marie@mjmontpetit.com <mailto:marie@mjmontpetit.com>> wrote:
>> Since most of your questions are related to FEC I copy the nwcrg. See <mjm> below
>> 
>> mjm
>> 
>> Marie-José Montpetit, Ph.D.
>> Research Affiliate, MIT Media Laboratory
>> mariejose@mjmontpetit.com <mailto:mariejose@mjmontpetit.com>
>> mariejo@mit.edu <mailto:mariejo@mit.edu>
>> On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>) wrote:
>> 
>>> Hi, Mirja, 
>>> 
>>> On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
>>> Hi Carsten, hi Spencer,
>>> 
>>> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>> wrote:
>>> >
>>> > My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-)
>>> 
>>> Yes, it would be possible to charter without another BoF a small and well-scoped group, however, it also would be possible to work on small and well-defined pieces of work without a new working group. This was one of the reasons why this was not a non-wg-forming BoF because it is not clear yet if a new group is needed or the resulting pieces of standardization work are small enough to fit into an existing group.
>>> 
>>> Therefore, I really recommend focus on defining the standardising work items that you think are needed rather than trying to do any word-smithing of a potential charter (that eventually is not needed).
>>> 
>>> Thanks for giving me the chance to clarify - I really was talking about chartering work, not just chartering a working group, but that wasn't clear from my note. As you said, knowing what the work is, in more detail, will help you and Magnus know what to do next. 
>>> 
>>> So, my suggestion for the interested community is to nail down
>>> In order to "do LOOPS", what already exists, that can be used without changes?
>>> what already exists, but needs to be extended for LOOPS?
>>> what needs to be created, because nothing exists that meets the needs?
>>>  I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a month before IETF 105), but speaking as someone who hasn't been involved in depth, I wonder about
>>> How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?
>> 
>> <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.
>> 
>>> 
>>> 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.
>> 
>> 
>> So, speaking with no dots because I don't have any, I agree with what Marie-Jose is saying here, but my understanding is that LOOPS endpoints might turn LOOPS off completely if local optimizations aren't needed. So I'm thinking about how a sender makes that decision, and how a sender might do trade-offs. 
>> 
>> I think one point in discussions with Marie-Jose might be that she's thinking in terms of Technical Specifications (https://tools.ietf.org/html/rfc2026#section-3.1 <https://tools.ietf.org/html/rfc2026#section-3.1>), which are necessary, but discussions are making me think that proponents might usefully also think in terms of Applicability Statements (https://tools.ietf.org/html/rfc2026#section-3.2 <https://tools.ietf.org/html/rfc2026#section-3.2>), which (quoting) 
>> 
>>    An Applicability Statement specifies how, and under what
>>    circumstances, one or more TSs may be applied to support a particular
>>    Internet capability.  An AS may specify uses for TSs that are not
>>    Internet Standards, as discussed in Section 7.
>> 
>>    An AS identifies the relevant TSs and the specific way in which they
>>    are to be combined, and may also specify particular values or ranges
>>    of TS parameters or subfunctions of a TS protocol that must be
>>    implemented..  An AS also specifies the circumstances in which the use
>>    of a particular TS is required, recommended, or elective (see section
>>    3.3).
>> 
>>    An AS may describe particular methods of using a TS in a restricted
>>    "domain of applicability", such as Internet routers, terminal
>>    servers, Internet systems that interface to Ethernets, or datagram-
>>    based database servers.
>> 
>> So, if Applicability Statements (also standards-track documents) would be helpful for LOOPS deployment and operation, the proponents might think about whether they want to do work in that space. 
>> 
>> If decisions about what senders do turn out to be entirely up to the sender, that's great, but if the proponents want to bound the possible behaviors of implementations to improve deployment and operation, that might also be appropriate in BCPs (https://tools.ietf.org/html/rfc2026#section-5 <https://tools.ietf.org/html/rfc2026#section-5>).
>>  
>>> 
>>> 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.
>> 
>> <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". 
>> 
>> Right - so one possibility is publishing work from NWCRG in the IETF stream, and especially standards-track, with appropriate review by the IETF community. That could take a lot of forms (RGs and WGs can interact in a lot of different ways). 
> 
> An IETF WG could have a work item to develop a standards track FEC scheme based on the research previously done in NWCRG, certainly.
>> <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?
>> 
>> 
>> See Mirja's note about chartering work, and only chartering working groups when that's needed. But as you note, the FECFRAME extensions happened in TSVWG, so that would be a reasonable conversation to have with TSVWG chairs (and I note that Wes Eddy, who popped up further down in this thread, is a TSVWG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in an existing working group, NWCWG could be a plan.  
> 
> I perhaps misunderstood LOOPS, but I’d assumed that – to the extent is uses FEC and not retransmission – it’d pull in one of the schemes developed in FECFRAME. Has there been any requirements analysis to show if anything further is needed?
> 
> That's the analysis that I'm suggesting the proponents work on now. I didn't talk to all the proponents in Montreal, but at least a couple were pretty sure they wanted to use FEC, but were still figuring out details on that usage. 
> 
> Marie-Jose and some other nice people from NWCRG are providing pointers to help with that analysis. For which, I'm grateful. I was the responsible AD for the recent sliding window FECFRAME extensions that migrated through TSVWG, and I understand FECFRAME at a 10,000-meter level, but the proponents (and interested parties) need to work through the next level of details.
> 
> This is separate to the question of whether there's work in NWCRG that’s ready to move into IETF for standardisation, of course. 
> 
> The nice thing about the existing relationship between NWCRG and TSVWG is that if there's more stuff from NWCRG that's ready to standardize in the IETF, we know how to do that, and Wes Eddy (one of the TSVWG co-chairs) is already helping with congestion discussion on this mailing list.
> 
> I think the non-working group-forming BOF did a good job at flushing out the questions and the resources needed to answer them. Thanks, Magnus and Mirja, for making that easy.
> 
> Spencer
> 
> Colin
> 
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>