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

[Marie-Jose Montpetit <[e-mail]>]

I think within the nwcrg we could discuss what is the best path. Just
bringing the work I agree is not the best way forward.

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
[e-mail]
[e-mail]

On August 20, 2019 at 6:50:47 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?

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/