Subject: [LOOPS] Charter github issue #6: FEC

From: Carsten Bormann <[email-masked]>
Date: Tue, 23 Jun 2020 12:35:42 +0200

In charter github issue #6 <https://github.com/loops-wg/charter/issues/6>,
larseggert writes:

»

Charter says:

> The initial focus will be on retransmission, but at least one FEC scheme will be included in order to exercise the protocol mechanisms for selecting FEC and a specific FEC scheme.

So if the initial interest is on RTX and not FEC, it's not clear that throwing in a FEC mechanism in order to try and make sure the protocol can support it will be successful - you don't know if the FEC mechanism actually works unless someone is really interested in deploying it.

Would it make sense to just drop FEC and instead try to keep the protocol extensible, so it can be added later, when there is an actual deployment interest in FEC schemes?

«

Right.  The objective for including this was that we need to have mechanism in place so we can support FEC in earnest once a few interesting schemes are added.  So the idea was to have one FEC option in the initial delivery.  If nobody deploys that, the effect desired (exercise the mechanism) will not be achieved.

Huawei’s prototype has a FEC mode, based on RFC 6330, as described in appendix A.1 of the gen-info document [0].
So my (maybe too) tacit assumption was that we should be able to throw together *something* for the initial deliverable that is actually useful enough to deploy as an MVP [1].  Then the game of coming up with FEC schemes and their parameters that are more optimal for various use cases could begin.

Putting in RFC 6330 might incur an IPR statement, so we might want to do something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead.  Well, not sure that this would be useful enough to deploy, except maybe in combination with retransmission.

As another alternative, we could try to enlist more help from nwcrg, to get a state-of-the art scheme in there right away.  But the engineering (and consensus building) needed for that would weaken the argument that we are building an MVP first.

What do you think?

Grüße, Carsten

[0]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-03#appendix-A.1
[1]: https://en.wikipedia.org/wiki/Minimum_viable_product

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 23 Jun 2020 06:47:10 -0400

(no nwcrg chair hat)

- The FEC in LOOPS could follow what we are proposing in QUIC which assumes
many potential solutions and an FEC “negotiation” at the beginning of the
season.

- There are some patents related to 6330 that expired so I gather you are
in the clear.

- But not all FECs are good for every traffic and yes some engineering
studies would be needed (and another reason to have a negotiation).

(nwcrg chair on) I suppose the group would be ready to help and in Prague
last year we had said so to the Huawei team.

mjm

Marie-José Montpetit, Ph.D.
[email-masked]

On June 23, 2020 at 6:35:54 AM, Carsten Bormann ([email-masked]) wrote:

»

Charter says:

> The initial focus will be on retransmission, but at least one FEC scheme
will be included in order to exercise the protocol mechanisms for selecting
FEC and a specific FEC scheme.

So if the initial interest is on RTX and not FEC, it's not clear that
throwing in a FEC mechanism in order to try and make sure the protocol can
support it will be successful - you don't know if the FEC mechanism
actually works unless someone is really interested in deploying it.

Would it make sense to just drop FEC and instead try to keep the protocol
extensible, so it can be added later, when there is an actual deployment
interest in FEC schemes?

«

Right. The objective for including this was that we need to have mechanism
in place so we can support FEC in earnest once a few interesting schemes
are added. So the idea was to have one FEC option in the initial delivery.
If nobody deploys that, the effect desired (exercise the mechanism) will
not be achieved.

Huawei’s prototype has a FEC mode, based on RFC 6330, as described in
appendix A.1 of the gen-info document [0].
So my (maybe too) tacit assumption was that we should be able to throw
together *something* for the initial deliverable that is actually useful
enough to deploy as an MVP [1]. Then the game of coming up with FEC schemes
and their parameters that are more optimal for various use cases could
begin.

Putting in RFC 6330 might incur an IPR statement, so we might want to do
something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. Well, not
sure that this would be useful enough to deploy, except maybe in
combination with retransmission.

As another alternative, we could try to enlist more help from nwcrg, to get
a state-of-the art scheme in there right away. But the engineering (and
consensus building) needed for that would weaken the argument that we are
building an MVP first.

What do you think?

Grüße, Carsten

-- 
LOOPS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/loops

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 23 Jun 2020 22:05:23 +0200

Dear all,
We are also interested in experimenting with different FEC schemes. So I 
think it would be a shame to drop the ability to at least somehow 
communicate a specific one.

All the best,
Morten

On 6/23/20 12:47 PM, Marie-Jose Montpetit wrote:
> (no nwcrg chair hat)
>
> - The FEC in LOOPS could follow what we are proposing in QUIC which 
> assumes many potential solutions and an FEC “negotiation” at the 
> beginning of the season.
>
> - There are some patents related to 6330 that expired so I gather you 
> are in the clear.
>
> (nwcrg chair on) I suppose the group would be ready to help and in 
> Prague last year we had said so to the Huawei team.
>
>
> mjm
>
>
> [email-masked] <mailto:[email-masked]>
>
>
>
> On June 23, 2020 at 6:35:54 AM, Carsten Bormann ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
>> In charter github issue #6 
>> <https://github.com/loops-wg/charter/issues/6>,
>> larseggert writes:
>>
>> »
>>
>> Charter says:
>>
>> > The initial focus will be on retransmission, but at least one FEC 
>> scheme will be included in order to exercise the protocol mechanisms 
>> for selecting FEC and a specific FEC scheme.
>>
>> throwing in a FEC mechanism in order to try and make sure the 
>> protocol can support it will be successful - you don't know if the 
>> FEC mechanism actually works unless someone is really interested in 
>> deploying it.
>>
>> Would it make sense to just drop FEC and instead try to keep the 
>> protocol extensible, so it can be added later, when there is an 
>> actual deployment interest in FEC schemes?
>>
>> «
>>
>>
>> Right. The objective for including this was that we need to have 
>> mechanism in place so we can support FEC in earnest once a few 
>> interesting schemes are added. So the idea was to have one FEC option 
>> in the initial delivery. If nobody deploys that, the effect desired 
>> (exercise the mechanism) will not be achieved.
>>
>> So my (maybe too) tacit assumption was that we should be able to 
>> throw together *something* for the initial deliverable that is 
>> actually useful enough to deploy as an MVP [1]. Then the game of 
>> coming up with FEC schemes and their parameters that are more optimal 
>> for various use cases could begin.
>>
>> Putting in RFC 6330 might incur an IPR statement, so we might want to 
>> do something based on RFC 5109 (RFC 2733) or SMPTE-2022 instead. 
>> Well, not sure that this would be useful enough to deploy, except 
>> maybe in combination with retransmission.
>>
>> As another alternative, we could try to enlist more help from nwcrg, 
>> to get a state-of-the art scheme in there right away. But the 
>> engineering (and consensus building) needed for that would weaken the 
>> argument that we are building an MVP first.
>>
>> What do you think?
>>
>> Grüße, Carsten
>>
>> [0]: 
>> https://tools.ietf.org/html/draft-welzl-loops-gen-info-03#appendix-A.1 
>> <https://tools.ietf..org/html/draft-welzl-loops-gen-info-03#appendix-A.1>
>> [email-masked] <mailto:[email-masked]>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Jun 2020 09:21:15 +0300

Hi,

On 2020-6-23, at 23:05, Morten V. Pedersen <[email-masked]> wrote:
> We are also interested in experimenting with different FEC schemes. So I think it would be a shame to drop the ability to at least somehow communicate a specific one.

we charter WGs because people want to ship compatible products and want specs to do so. You don't need a standard for experimentation. Especially a new WG should IMO focus on those pieces that are ready for products, not on experiments.

We do of course publish Experimental RFCs in the IETF. The purpose of those is to inform the community of an experiment that is being conducted, often with enough details to allow others to join into the experiment. But those can be Individual drafts or done in the IRTF.

Lars

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Wed, 24 Jun 2020 08:43:22 +0200

Hi,
Don't get me wrong we make a living selling these FEC components.

However, different FEC schemes have different properties. It is not 
clear to me that there is one scheme to rule them all. Therefore I do 
believe it would be wise to include a way to select/negotiate which 
scheme to use.

All the best,
Morten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Jun 2020 09:04:56 +0200

On 2020-06-24, at 08:43, Morten V. Pedersen <[email-masked]> wrote:
> 
> However, different FEC schemes have different properties. It is not clear to me that there is one scheme to rule them all.

After having worked with different FEC schemes, I definitely concur.
(One of the properties that cannot be ignored is non-technical: encumbrance, and different users may have quite different requirements here as well.)

> Therefore I do believe it would be wise to include a way to select/negotiate which scheme to use.

Right.  My assumption is that for each FEC scheme, we will have a registered identifier/name (possibly piggy-backing on some other registry), as well as a set of parameters that need to be set to .

The original plan for LOOPS was to set these identifiers/parameters in a controller-based setup protocol that is out of scope.  For a batteries-included spec, we probably need to specify such a controller-based setup protocol (essentially, say, a YANG data model) and/or a peer-to-peer setup protocol; the latter could leverage the same YANG data structure.  (Or we could forego YANG here and use plain-old-CBOR-items, PoCI.)

I think all these considerations are quite self-evident to experienced protocol designers, so I would not expect much discussion (except maybe for bike-shedding YANG vs. PoCI); I also don’t think the charter has to say much about this.

Limiting ourselves to one FEC scheme in the initial delivery wouldn’t obviate any of this machinery (to the converse: we are doing this to exercise this machinery); it would just mean we defer the selection of “state-of-the-art” FEC schemes (and the accompanying experiments/measurements) to a later phase.  I mentioned RFC 6330 and RFC 5109 as both can be used as the blueprint for such a scheme; one has a higher recovery probability and the other has a lower implementation and CPU complexity.  Again, this does not have to be decided in the charter, and I don’t expect a strong preference for either, as they are both a bit pedestrian by now (OK, RFC 6330 probably is a bicycle :-).

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jun 2020 09:43:51 -0500

Just following on Lars' point about IETF work targeting interoperation, the
idea of focusing on one FEC scheme to make sure that the retransmission/FEC
decision is included in LOOPS seems good.

Is this likely to turn into a mandatory-to-implement FEC scheme in the
protocol specification(s)?

Best,

Spencer

On Wed, Jun 24, 2020 at 2:06 AM Carsten Bormann <[email-masked]> wrote:

> clear to me that there is one scheme to rule them all.
>
> (One of the properties that cannot be ignored is non-technical:
> encumbrance, and different users may have quite different requirements here
> as well.)
>
> Right.  My assumption is that for each FEC scheme, we will have a
> registered identifier/name (possibly piggy-backing on some other registry),
> as well as a set of parameters that need to be set to .
>
> The original plan for LOOPS was to set these identifiers/parameters in a
> controller-based setup protocol that is out of scope.  For a
> batteries-included spec, we probably need to specify such a
> controller-based setup protocol (essentially, say, a YANG data model)
> and/or a peer-to-peer setup protocol; the latter could leverage the same
> YANG data structure.  (Or we could forego YANG here and use
> plain-old-CBOR-items, PoCI.)
>
> I think all these considerations are quite self-evident to experienced
> protocol designers, so I would not expect much discussion (except maybe for
> bike-shedding YANG vs. PoCI); I also don’t think the charter has to say
> much about this.
>
> Limiting ourselves to one FEC scheme in the initial delivery wouldn’t
> obviate any of this machinery (to the converse: we are doing this to
> exercise this machinery); it would just mean we defer the selection of
> “state-of-the-art” FEC schemes (and the accompanying
> experiments/measurements) to a later phase.  I mentioned RFC 6330 and RFC
> 5109 as both can be used as the blueprint for such a scheme; one has a
> higher recovery probability and the other has a lower implementation and
> CPU complexity.  Again, this does not have to be decided in the charter,
> and I don’t expect a strong preference for either, as they are both a bit
> pedestrian by now (OK, RFC 6330 probably is a bicycle :-).
>
> Grüße, Carsten
>
> --
> LOOPS mailing list
> [email-masked]

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 24 Jun 2020 07:59:17 -0700

(no hat) In our QUIC to avoid the IPR issues that could be related to
specifying the FEC and to give the system operator some traffic fine-tuning
we do allow more than one scheme. It’s not experimentation. It’s just
agnostic.

mjm

On June 24, 2020 at 10:44:26 AM, Spencer Dawkins at IETF (
[email-masked]) wrote:

Best,

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Jun 2020 18:00:57 +0200

On 2020-06-24, at 16:43, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Just following on Lars' point about IETF work targeting interoperation, the idea of focusing on one FEC scheme to make sure that the retransmission/FEC decision is included in LOOPS seems good. 
> 
> Is this likely to turn into a mandatory-to-implement FEC scheme in the protocol specification(s)?

If you ask me:

“Default” (hey, get this in so we get some interop): Yes.
"MTI" (you must put this in or you can’t play): probably not.

Grüße, Carsten

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Wed, 24 Jun 2020 18:59:53 +0200

> "MTI" (you must put this in or you can’t play): probably not.

Sounds like a reasonable approach.

- M