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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Colin,

On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins <[e-mail]> 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 <[e-mail]>
> 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 ([e-mail]) 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 <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/loops
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>