Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
Marie-Jose Montpetit <marie@mjmontpetit.com> Thu, 22 August 2019 11:22 UTC
Return-Path: <marie@mjmontpetit.com>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A122312004E for <loops@ietfa.amsl.com>; Thu, 22 Aug 2019 04:22:54 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mKpsooR8E3fU for <loops@ietfa.amsl.com>; Thu, 22 Aug 2019 04:22:52 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 3458A120026 for <loops@ietf.org>; Thu, 22 Aug 2019 04:22:52 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id j4so2724083iog.11 for <loops@ietf.org>; Thu, 22 Aug 2019 04:22:52 -0700 (PDT)
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=0xvNjYV0TV0SQI9BV7bQqO8M528qKnUR2Jyp9gZ5/RI=; b=zz/tO2mG7Lguh4trBzF9J1q5IfKNXKR8NfcSE2W3Wn7LX3nIeTI6L7+SnUEByj3yEd a6ruKct4ctwTItg1c8QGio6JRDZ/Mz0yVjvgWGSgLbgARWo/FRADReYis10azoOUcWNN B9OgMdPILk/JgLxsljChcD3RQ+YCAFJHAxQV5PapqzRRWv/MveJ0Q0BI5kUYdhLaoR3z 6o3nkHVt88fnkOTf3m6QPsIDwQjaZSNo3/AIfks1guO2QwKkLNV6u4Cgf3t4natHfB71 7VTZY5fzV78e+Yx8/E3Ub7j24djFrJ8SUTftXayL6+0YIqVDY+5OEacyuBVkg9QuK2gE r02g==
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=0xvNjYV0TV0SQI9BV7bQqO8M528qKnUR2Jyp9gZ5/RI=; b=YrXvTeHBmBVQgz/XirsSWnvvmm/jMlrlH1ueSVtmsQNDzEYM7lzH1sCIsEVIitRFpu d9WzcgRy9n/1nZysdRysmAGRGwK3uMon0XS4lC8by8nNlgIFvL5z0W+zLH9ierqz3JQM R/R67Hr2IGyJ617xW2lrosg0ZQL39SwoVz+gjqmaD0KqdQSFdg/6mYrLUeJ/qrzIM73y 2iV5dhKqFyILivFjbZkVmud2Kk8pQlkeaba4NvFEfTBcaffgtrptdqL1aNOSJZ+0nO+a hmEUvLmF1TGen6NhEItFiLPh2/fbR0Bp7crWljiJ8+wtwbTJYe0MXqTRxPM/1AAlsCPL Nzvw==
X-Gm-Message-State: APjAAAUFTWU/UGJQg5HajI8eoITVWEshGIJm6P6IHm1hZEc946+PSFWW Bqm5ul5XPolSFreq2txL5537Be+5Z93WS+/GTsyNEQ==
X-Google-Smtp-Source: APXvYqwecWC+OfKKR/iKXXf2s6MWOhlRNfcVAq3TWmtvEAqX9H2pIbmC7UyHfIL4Y6IagtuEvKp9bMAOw38Gw4xyAj4=
X-Received: by 2002:a5e:a502:: with SMTP id 2mr19653273iog.269.1566472971380; Thu, 22 Aug 2019 04:22:51 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 22 Aug 2019 07:22:50 -0400
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.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> <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> <CAPjWiCQ=bWFND6=9mg-1iWCNJeQs6doQ+WT5aqT5m23XS5f=8A@mail.gmail.com> <CBD55148-D49B-4218-AE40-5E7ED35B7E86@csperkins.org> <CAKKJt-f7AQUEafJyWbHk=pjfsFg0dZ3XhDBsP0=mb5jSD6GYNA@mail.gmail.com> <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.org> <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.org>
MIME-Version: 1.0
Date: Thu, 22 Aug 2019 07:22:50 -0400
Message-ID: <CAPjWiCS5hyqNrei4nEEqXe=JY_obEy1iDD03Khopv9GvAR8vPw@mail.gmail.com>
To: Colin Perkins <csp@csperkins.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Suresh Krishnan <suresh@kaloom.com>, Vincent Roca <vincent.roca@inria.fr>, Carsten Bormann <cabo@tzi.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, loops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000282130590b2e931"
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/aUYwqyf_pul_2rPbaAYZGys_MqQ>
Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 11:22:55 -0000
Just an add on: Besides the code that was presented within FECFRAME, NWCRG is also working on API for sliding window codes: https://datatracker.ietf.org/doc/draft-roca-nwcrg-generic-fec-api/ And of course we have a hackaton to develop an open source codec and the LOOPS community is more that welcome to participate. mjm Marie-José Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On August 22, 2019 at 4:29:11 AM, Colin Perkins (csp@csperkins.org) wrote: Makes sense – although as you say, it’s for Magnus and Mirja to decide. Colin On 22 Aug 2019, at 05:23, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: Hi, Colin, On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins <csp@csperkins.org> wrote: > One of the things we’d need to decide is what’s the path from NWCRG into > IETF to standardise such things before use by LOOPS. > > FECFRAME seemed to work quite well. Is the goal to revive it and move some > work from NWCRG? Or to bring work from NWCRG into TSVWG to do FECFRAME > extensions for LOOPS to reference? Or to bring work from NWCRG into LOOPS? > It seemed to me that doing the sliding window FECFRAME extension in TSVWG worked well enough (modulo a really amazing kerfluffle on getting a PRNG implementation that we could publish in an IETF RFC), although that decision would be up to Magnus and Mirja, at this point in the process. But the TSVWG co-chairs are already trained on what would be required from them. Spencer > I’d suggest either of the former two options make more sense than the > latter. > > Colin > > > > On 20 Aug 2019, at 11:42, Marie-Jose Montpetit <marie@mjmontpetit.com> > wrote: > > Not “excitement" but some of the FEC control mechanisms as well as the > encapsulation and aggregated flow protocols that you want to investigate > are part of the work in the nwcrg (and yes not the IETF) and I would hope > that they will be reused by LOOPS. > > mjm > > Marie-José Montpetit > > On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote: > > Hi Spencer, > > It is probably not too easy to generate a lot of excitement on this list > while most people are still on vacation, but let me try to answer your > questions. > > > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > […] > > 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? > > Most of IP :-) > > Seriously, the idea behind LOOPS is to use existing tunnel encapsulation > protocols with few additions, capitalizing on that work, and also making > use of ASIC support already present in devices — it helps to be > encapsulation-agnostic for this. > > It is unlikely that we’ll have to invent another FEC scheme for LOOPS, so > existing schemes can probably be used unchanged. I’m not so sure the WG > won’t want to improve on the FECFRAME framework, though. I don’t want to > design much of the protocol while we are still in a WG-forming stage, so > I’ll refrain from delving too much on why I think that may be a good thing. > Basically, think about packet size distributions in general aggregated IP > flows vs. those in the RTP flows or even single transport flows that > FECFRAME schemes are being used with. > > Most likely, the time stamp formats (and even some algorithms around > those) we need can be stolen from existing work. > > Not much else can probably be used unchanged. > > > • what already exists, but needs to be extended for LOOPS? > > The encapsulation schemes may need to have their extension points > exercised to actually send the forward and reverse information in the best > way. Some of the encapsulation protocols already define how to carry a > sequence number, but other elements (such as block 1 and block 2 reverse > information [1]) may need some encoding decisions. > > > • what needs to be created, because nothing exists that meets the needs? > > The actual protocol, i.e., the rules of action. (A best-effort, not fully > reliable retransmit scheme; FEC parameter control loops; measurement > schemes that go into these and into congestion feedback mechanisms.) > > > 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? > > I’m not aware of such a control loop in existing IETF standards, but I > would love to be surprised. > > > • How a sender knows whether to do FEC, retransmission, or both FEC and > retransmission, dynamically? > > In most cases, this will be setup information (controller model). > > > • How a sender knows that it shouldn’t be doing anything, because > anything it does won't help ("first, do no harm")? > > Again, probably setup information. The protocol could also define some > thresholds for switching components on an off, on a relatively long time > scale. > > > Does everyone know how to do those three things, except me? :-) > > I hope the WG can find out once it exists… > > I would also like to avoid the FEC tail wagging with the LOOPS dog too > much. > (I know, if you are standing very close to the tail, it may seem larger > than the dog :-) > > Yes, the sheer bulk and complexity of the specifications is larger in the > FEC part than in the rest of the specifications. But then, FEC is > relatively well understood, a lot of (re-)usable specifications are out > there, and we even have a whole RG for that which we can tap. On the other > hand, doing best-effort retransmissions (and FEC) on aggregate flows while > we are experiencing increased presence of new-style end-to-end transports > (encrypted, more reordering-tolerant) is a new engineering problem that > needs a bit more focus from the WG. > > .oOo. > > By the way, I have generated a post-ietf105 branch on the charter text > proposal [charter-0.3] that explicitly calls out focusing on retransmission > initially and adding FEC later (with or without a rechartering needed); > this version also adds milestones for a (shim-layer-in-)host-to-network > component that was requested so vividly at the BOF. > > Grüße, Carsten > > [1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3 > [2]: https://github.com/loops-wg/charter/tree/post-105 > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > -- Colin Perkins https://csperkins.org/
- [LOOPS] BOF co-chairs thinking on LOOPS next steps Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Michael Welzl
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Liyizhou
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Mirja Kuehlewind
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Emmanuel Lochin
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Wesley Eddy
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Wesley Eddy
- Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOO… Stuart William Card
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Michael Welzl
- Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOO… Colin Perkins
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Wesley Eddy
- Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOO… Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … mohamed.boucadair
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … mohamed.boucadair
- Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOO… Colin Perkins
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Michael Welzl
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Carsten Bormann
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Colin Perkins
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Spencer Dawkins at IETF
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Colin Perkins
- Re: [LOOPS] BOF co-chairs thinking on LOOPS next … Marie-Jose Montpetit