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

[Carsten Bormann <[e-mail]>]

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