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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jul 2019 11:24:43 -0400

Hi, Magnus,

Ole and I wanted to let you know what things looked like to us as
co-chairs.

We are copying the mailing list, to provide transparency for the LOOPS
community. Wes Hardaker suggested that we copy the IAB because at least two
IAB folk were covering the BOF, and would be sending write-ups to the IAB
and IESG afterwards.

(Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail
on the mailing list. Interested IAB members are subscribed to LOOPS, or
will be very soon. Uninterested IAB members don't need more e-mail from us!)

First, I'd like to thank you (and Suresh) for bringing in an INT co-chair.
That was extremely helpful.

Draft minutes have been posted at
https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize ...

We asked these questions at the beginning of the BOF:

Chairs: What sort of people were in the room?

   - 1/3 transport people
   - 1/3 encaps people
   - 1/10 apps people
   - 2 ops people
   - 5 measurements people
   - 1.5 security people
   - 10-12 people on products/systems they do some form of enhancement.
   - Who has read the problem draft?  1/3 room

We think that holding a BOF was a good decision, based on the number of
people (even in the room) working on products and systems in this space.

We think that holding a non-working group-forming BOF was a good decision,
because many of the people who have been working in this space haven't been
talking to each other (which makes products that don't interoperate or
provide the same services in the same way - same as our previous experience
with NATs). Providing a place for them to talk was very helpful.

Ole was impressed at the low number of tourists in the room.

The key points from the BOF proponents were

   - First, do no harm - measure what you're doing, and adjust what you're
   doing based on feedback, including turning your optimizations off entirely.
   - Do local repair between LOOPS endpoints, not involving hosts (at
   least, not now)
   - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out
   of scope (at least for now)
   - Use FEC for local repair
   - Do The Right Thing in tuning FEC usage based on feedback
   - In some cases, use limited retransmission for local repair, probably
   if FEC is not sufficient

The key points from discussion were

   - Marie-Jose Montpetit, co-chair of Network Coding Research Group, said
   that they have much research that is applicable for FEC. Marie-Jean has
   followed up on the mailing list after the BOF.
   - It's not clear how much vendors in this space want a standardized
   solution, but it's more likely that operators will want that
   - Multiple people have concerns about masking signals about actual
   losses and adverse interactions between multiple levels of optimizations.
   These are things to watch out for in future work

Hums at the end of the session were

   - There are multiple problems involved here, so a key next step will be
   teasing those problems apart and identifying what the IETF (and IRTF) has
   already done, that is applicable, and could be reused with no changes, or
   extended/modified as part of LOOPS, and what problems still remain
   unaddressed and clearly require protocol work in the IETF
   - Colin Perkins said there were big parts of the LOOPS problem set that
   are engineering now (Spencer and Ole happen to agree)
   - Andrew McGregor said that LOOPS would benefit from additional research
   (Spencer and Ole happen to agree, but think there is enough engineering
   work that waiting for more research to charter work isn't necessary)
   - Magnus asked if standardization in this space would be useful or
   beneficial. Many hums YES, some hums NO.

We will send our recommendations on how to follow up to the LOOPS mailing
list separately, so that the discussion happens in the right place. If IESG
and IAB people have opinions about that, subscribing would be good :-)

We can imagine that work in this space would result in standards-conformant
products, but we can also imagine that work in this space would result in
significantly improved proprietary products, or standards-conformant
products with significant extensions. A lot depends on the people doing the
work.

Thanks for the opportunity to serve the community in this way.

Spencer and Ole, as co-chairs for the BOF

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 24 Jul 2019 08:30:37 -0700

There was no Marie-Jean follow up. It was only me :)

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

On July 24, 2019 at 11:24:43 AM, Spencer Dawkins at IETF (
[email-masked]) wrote:

>    - First, do no harm - measure what you're doing, and adjust what
>    you're doing based on feedback, including turning your optimizations off
>    entirely.
>    - Marie-Jose Montpetit, co-chair of Network Coding Research Group,
>    said that they have much research that is applicable for FEC. Marie-Jean
>    has followed up on the mailing list after the BOF.
>    - There are multiple problems involved here, so a key next step will
>    be teasing those problems apart and identifying what the IETF (and IRTF)
>    has already done, that is applicable, and could be reused with no changes,
>    or extended/modified as part of LOOPS, and what problems still remain
>    - Colin Perkins said there were big parts of the LOOPS problem set
>    that are engineering now (Spencer and Ole happen to agree)
>    - Andrew McGregor said that LOOPS would benefit from additional
>    research (Spencer and Ole happen to agree, but think there is enough
>    engineering work that waiting for more research to charter work isn't
>    necessary)
> We can imagine that work in this space would result in
> standards-conformant products, but we can also imagine that work in this
> space would result in significantly improved proprietary products, or
> standards-conformant products with significant extensions. A lot depends on
> the people doing the work.
>
> --
> LOOPS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/loops
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jul 2019 11:32:58 -0400

Marie-Jose,

> There was no Marie-Jean follow up. It was only me :)

My apologies for horrible mental pattern matching! It was definitely you ;-)

Best regards,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jul 2019 17:40:03 -0400

Dear All,

I met with the ADs to talk about the next steps they would like to see for
LOOPS.

Here's what I know.

   - There are people working in this space now
   - The community thinks standardization would help
   - What's necessary is to identify exactly what work is required, so that
   the ADs can make decisions about where that work should take place.
   - We got some suggestions about technologies that could be used in LOOPS
   at the BOF. That will be a great starting point.
   - Here's a hint from the ADs - if the proponents can come up with a
   clear charter, limited in scope, that will make their lives easier, and
   make it easier for them to charter this work :D

I told Magnus I was willing to work with the LOOPS community as you move
forward toward a charter.

Make good choices!

Spencer

On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>    said that they have much research that is applicable for FEC. Marie-Jose

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 24 Jul 2019 15:17:28 -0700

Standardisation of what? The architecture? The protocols (beware there is
already FECFRAME and others)? The proxies?

mjm

On July 24, 2019 at 5:40:03 PM, Spencer Dawkins at IETF (
[email-masked]) wrote:

>    - What's necessary is to identify exactly what work is required, so
>    that the ADs can make decisions about where that work should take place.
>    - We got some suggestions about technologies that could be used in
>    LOOPS at the BOF. That will be a great starting point.
>> First, I'd like to thank you (and Suresh) for bringing in an INT
>> co-chair. That was extremely helpful.
>>
>> We think that holding a non-working group-forming BOF was a good
>> decision, because many of the people who have been working in this space
>> haven't been talking to each other (which makes products that don't
>> interoperate or provide the same services in the same way - same as our
>> previous experience with NATs). Providing a place for them to talk was very
>> helpful..
>>
>>    - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were
>>    out of scope (at least for now)
>>    - In some cases, use limited retransmission for local repair,
>>    probably if FEC is not sufficient
>>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 00:56:33 -0400

On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> Standardisation of what? The architecture? The protocols (beware there is already FECFRAME and others)? The proxies?

Hi Marie-José,

details of the thinking that was developed in the side meetings that happened at the previous two IETF meetings can be found at

https://github.com/loops-wg/charter

The BOF actually added one piece of information I didn’t previously perceive that way:
People seem to really want to tackle the host-to-node case (as needed, e.g., for going through WiFi access clouds) right away, not just the in-network (node-to-node) case.  That would be the one thing I would change based on my recollection of the BOF.  But of course there may be other things; it may be worth to now have another round of discussion of the proposed charter.

Grüße, Carsten

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 25 Jul 2019 03:32:44 -0700

Actually the wifi to node segment was the original use case fo the nwcrg.

mjm

On July 25, 2019 at 12:56:37 AM, Carsten Bormann ([email-masked]) wrote:

Hi Marie-José,

details of the thinking that was developed in the side meetings that
happened at the previous two IETF meetings can be found at

The BOF actually added one piece of information I didn’t previously
perceive that way:
People seem to really want to tackle the host-to-node case (as needed,
e.g., for going through WiFi access clouds) right away, not just the
in-network (node-to-node) case. That would be the one thing I would change
based on my recollection of the BOF. But of course there may be other
things; it may be worth to now have another round of discussion of the
proposed charter.

Grüße, Carsten

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 25 Jul 2019 05:34:54 -0700

Adding the nwcrg list to list thread. And with my NWCRG co-chair hat on.

Like I mentioned the WIFI to node hop was one of the original successes of
network coding as Prof. Médard and her team can attest to. A lot of the
LOOPS use cases for per hop network optimization have been not only
*researched* but *implemented* with running code by many of the nwcrg
participants.

NWCRG-ites; there was a LOOPS BOF on Monday to address the issues of
performance in multiple hop networks and Carsten is pointing to the related
material.

mjm

Hi Marie-José,

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Jul 2019 11:12:36 -0400

Hi, Marie-Jose,

> already FECFRAME and others)? The proxies?

Speaking as a chair for the IETF 105 BOF, which has already happened, so I
have no special status in this discussion :-)

I think that's a question that should guide LOOPS participants as they
discuss items for a proposed charter. You mention a couple of
possibilities, but in addition, the IETF can produce BCPs that explain how
to use existing protocols and mechanisms effectively to improve
performance. The IETF can also produce standards-track Applicability
Statements that describe when those existing protocols and mechanisms
should, and should not, be used.

So there are a number of possible answers to your question, and IMO the
LOOPS community should be looking at what exists today in more detail,
including NWCRG work that is applicable, and then proposing a charter that
includes what is needed, but does not yet exist.

Past IESGs have referred to this as "maps and gaps analysis" - mapping what
you need to do onto mechanisms that already exist, identifying gaps in
those mechanisms, and then deciding what to do, to fill in those gaps.

Best regards,

Spencer

>> I met with the ADs to talk about the next steps they would like to see
>> for LOOPS.
>>
>> Here's what I know.
>>
>>> (Dear LOOPists - you may wish to remove the IAB from any follow-up
>>> e-mail on the mailing list. Interested IAB members are subscribed to LOOPS,
>>> or will be very soon. Uninterested IAB members don't need more e-mail from
>>> us!)
>>>
>>> We will send our recommendations on how to follow up to the LOOPS
>>> mailing list separately, so that the discussion happens in the right place.
>>> If IESG and IAB people have opinions about that, subscribing would be good
>>> :-)
>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 Jul 2019 14:59:10 -0400

Still wearing no hats, because I no longer have any dots ...

On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <[email-masked]> wrote:

> > Standardisation of what? The architecture? The protocols (beware there
> is already FECFRAME and others)? The proxies?
>
> Hi Marie-José,
>

Communication is good, but one thing I mentioned in my summary of my chat
with the ADs was

So, it's reasonable for the LOOPS community to consider adding
host-to-node, but it's worth checking whether this would expand the scope
of the requested charter, and whether excluding host-to-node makes the
initial work easier to complete.

My impression, and Magnus might say I'm insane, was that Magnus is right on
the edge of whether this work can be chartered without a second, working
group-forming BOF. If the LOOPS community can't live without host-to-node,
the community should add it. If the community can make use of LOOPS without
host-to-node and add it later, the community might consider whether that
reduces the scope of the initial proposed charter enough to help Magnus
approve it :-)

Best wishes,

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2019 15:10:34 -0400

On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> […] If the LOOPS community can’t live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) 

Right.  One other place where we can structure the milestones further is by starting with retransmission mode only and add FEC mode in a second step.

So this would give us a nice and small first deliverable (retransmission mode for node-to-node) that we can then recharter from.  If we do this right, this doesn’t even need to increase the time up to when we deliver the whole protocol including both host-to-node and FEC.

Grüße, Carsten

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 25 Jul 2019 12:13:29 -0700

Which begs the question if the retransmission delay will kill the
application.

mjm

On July 25, 2019 at 3:10:39 PM, Carsten Bormann ([email-masked]) wrote:

On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF <
[email-masked]> wrote:
>
> […] If the LOOPS community can’t live without host-to-node, the community
should add it. If the community can make use of LOOPS without host-to-node
and add it later, the community might consider whether that reduces the
scope of the initial proposed charter enough to help Magnus approve it :-)

Right. One other place where we can structure the milestones further is by
starting with retransmission mode only and add FEC mode in a second step.

So this would give us a nice and small first deliverable (retransmission
mode for node-to-node) that we can then recharter from. If we do this
right, this doesn’t even need to increase the time up to when we deliver
the whole protocol including both host-to-node and FEC.

Grüße, Carsten

---

From: Michael Welzl <[email-masked]>
Date: Thu, 25 Jul 2019 15:27:45 -0400

Not if the egress doesn't re-sequence.

Then the worst thing that can happen (except for congestion in the LOOPS segment itself, which the LOOPS nodes should avoid) is that the retransmission doesn’t help.
It does help, though:
- for reasonably re-ordering robust TCP implementations (I’m not even talking about RACK: spurious loss recovery mechanisms such as F-RTO are also widely deployed)
- for, e.g., UDP-based applications that might not care about re-ordering  (I’m not an expert enough on RTP to know how many RTP applications could handle some degree of re-ordering too, but I suspect it’s a fair amount)
- for application-limited scenarios where a new packet might not even appear in time to create re-ordering; the last data packet of a TCP connection (tail loss) is such a case.

So I’m an advocate of “never create extra delay”. Delay is bad, and it’s hard to know what “just the right amount” of extra delay is (it depends on too many factors IMO).

Cheers,
Michael

> On Jul 25, 2019, at 3:13 PM, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> Which begs the question if the retransmission delay will kill the application.
> 
> mjm
> 
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> On July 25, 2019 at 3:10:39 PM, Carsten Bormann ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote: 
>> >

---

From: Liyizhou <[email-masked]>
Date: Thu, 25 Jul 2019 19:31:27 +0000

As applications have not been killed by end to end retransmission, I believe they are ok with shorter retransmissions.
Certainly we need to design it in a right way. And it is part of the work LOOPS is trying to do.

Rgds,
Yizhou

发件人： Marie-Jose Montpetit<[email-masked]<mailto:[email-masked]>>
收件人： Spencer Dawkins at IETF<[email-masked]<mailto:[email-masked]>>;Carsten Bormann<[email-masked]<mailto:[email-masked]>>
抄送： Magnus Westerlund<[email-masked]<mailto:[email-masked]>>;Mirja Kuehlewind<[email-masked]<mailto:[email-masked]>>;Suresh Krishnan<[email-masked]<mailto:[email-masked]>>;loops<[email-masked]<mailto:[email-masked]>>
主题： Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
时间： 2019-07-25 15:13:53

mjm

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

On July 25, 2019 at 3:10:39 PM, Carsten Bormann ([email-masked]<mailto:[email-masked]>) wrote:

Grüße, Carsten

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 30 Jul 2019 12:34:37 +0200

Hi Carsten, hi Spencer,

> On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) 

Yes, it would be possible to charter without another BoF a small and well-scoped group, however, it also would be possible to work on small and well-defined pieces of work without a new working group. This was one of the reasons why this was not a non-wg-forming BoF because it is not clear yet if a new group is needed or the resulting pieces of standardization work are small enough to fit into an existing group. 

Therefore, I really recommend focus on defining the standardising work items that you think are needed rather than trying to do any word-smithing of a potential charter (that eventually is not needed).

Mirja

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 30 Jul 2019 04:34:13 -0700

I fully agree with Mirja. There are pieces already being implemented in
existing groups.

On July 30, 2019 at 6:34:46 AM, Mirja Kuehlewind ([email-masked])
wrote:

Hi Carsten, hi Spencer,

> My impression, and Magnus might say I'm insane, was that Magnus is right
on the edge of whether this work can be chartered without a second, working

Yes, it would be possible to charter without another BoF a small and
well-scoped group, however, it also would be possible to work on small and
well-defined pieces of work without a new working group. This was one of
the reasons why this was not a non-wg-forming BoF because it is not clear
yet if a new group is needed or the resulting pieces of standardization
work are small enough to fit into an existing group.

Therefore, I really recommend focus on defining the standardising work
items that you think are needed rather than trying to do any word-smithing
of a potential charter (that eventually is not needed).

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 30 Jul 2019 09:22:26 -0500

Hi, Mirja,

> of a potential charter (that eventually is not needed).

Thanks for giving me the chance to clarify - I really was talking about
chartering work, not just chartering a working group, but that wasn't clear
from my note. As you said, knowing what the work is, in more detail, will
help you and Magnus know what to do next.

So, my suggestion for the interested community is to nail down

   1. In order to "do LOOPS", what already exists, that can be used without
   changes?
   2. what already exists, but needs to be extended for LOOPS?
   3. what needs to be created, because nothing exists that meets the needs?

 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

   1. How a sender tunes FEC dynamically - is that automatic, based on FEC
   mechanisms people are thinking about, or is there work to do there?
   2. How a sender knows whether to do FEC, retransmission, or both FEC and
   retransmission, dynamically?
   3. How a sender knows that it shouldn't be doing anything, because
   anything it does won't help ("first, do no harm")?

Does everyone know how to do those three things, except me? :-)

Pointers to specifications would be awesome ...

Spencer

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 30 Jul 2019 07:42:14 -0700

Since most of your questions are related to FEC I copy the nwcrg. See <mjm>
below

mjm

On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF (
[email-masked]) wrote:

Hi, Mirja,

<mjm> There are FEC mechanisms to adapt coding dynamically based on
acknowledgments for example. In the QUICK implementation we will have flag
a RECOVERED packet that could be used to adapt the coding rate. Other
implementations or code-specific protocols are also available.

   1.
   How a sender knows whether to do FEC, retransmission, or both FEC and
   retransmission, dynamically?

<mjm> Well the use of FEC (or not) is a design decision.  Of course you
need the code (and the libraries). And then the decision will be based on
known link condition, goodput, expected performance, type of traffic
(video, time sensitive etc.). And finding a tunnel and PEPs if you need to.
And it can depend on path statistics and not being end to end. I am not
sure you could standardize that decision.

   1.
   How a sender knows that it shouldn't be doing anything, because anything
   it does won't help ("first, do no harm")?

<mjm> Of course in a congested network doing nothing is probably best.
Again there is a lot of work on the interaction of coding and congestion
control.

<mjm> Not everyone knows the things but there has been a lot of work in
FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work
was done in a research group not a working group. But real implementations
exist in famous “networks".

<mjm> Since most of your questions are about erasure coding (coding for
packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG?

mjm

Spencer

LOOPS mailing list
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jul 2019 17:01:27 +0200

Hi Marie-José,

> <mjm> There are FEC mechanisms to adapt coding dynamically based on acknowledgments for example. In the QUICK implementation we will have flag a RECOVERED packet that could be used to adapt the coding rate. Other implementations or code-specific protocols are also available.

Right.  So a LOOPS variant will still need to be developed.

>> 	• 
>> How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
> <mjm> Well the use of FEC (or not) is a design decision.  Of course you need the code (and the libraries). And then the decision will be based on known link condition, goodput, expected performance, type of traffic (video, time sensitive etc.). And finding a tunnel and PEPs if you need to. And it can depend on path statistics and not being end to end. I am not sure you could standardize that decision.

What can be decided unilaterally does not need to be standardized.
Information that needs to be collected in cooperation between both ends to enable this decision (“measurement information”) may need to be standardized.

In any case, the LOOPS stance to setting up the channel is a “controller model”, i.e. we don’t plan to have negotiation or some such in the protocol, but expect a controller to set up both ends in a coordinated way.  This is probably the biggest item that needs to be added to enable host-to-node mode, as the host is less likely to be involved in that controller model (even though it could be, that part would then also need to be standardized).

>> How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")?
> <mjm> Of course in a congested network doing nothing is probably best. Again there is a lot of work on the interaction of coding and congestion control.

Right, which would need to be worked out into a protocol plus at least some basic best current practice algorithms for LOOPS.

> <mjm> Not everyone knows the things but there has been a lot of work in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work was done in a research group not a working group. But real implementations exist in famous “networks”. 

Great.  So let’s start to identify those documents that are nearly ready to be used and fit well.  E.g., for NWCRG, I’m aware of:

  "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)
  Schemes for FECFRAME", Vincent Roca, Belkacem Teibi, 2019-06-18,
  <draft-ietf-tsvwg-rlc-fec-scheme-16.txt>

and possibly (I’m not sure yet LOOPS will be a straightforward application of FECFRAME):

  "Forward Error Correction (FEC) Framework Extension to Sliding Window
  Codes", Vincent Roca, Ali Begen, 2019-01-11,
  <draft-ietf-tsvwg-fecframe-ext-08.txt>

> 
> <mjm> Since most of your questions are about erasure coding (coding for packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG?

In a certain way, very much so.  Now LOOPS is intended to have a retransmission mode, too, which probably would go beyond standard fare of NWCRG.  I’m also not sure that the finer points of measurement that are needed (bilaterally) to enable really good LOOPS implementations (mostly unilaterally) are covered in NWCRG, and I’m also not sure about congestion feedback.  But I wouldn’t mind to call the thing NWCWG, as long as we get to ship the retransmission mode first.

Grüße, Carsten

---

From: Emmanuel Lochin <[email-masked]>
Date: Tue, 30 Jul 2019 17:14:37 +0200

Hi Spencer, all,

On 30/07/2019 16:22, Spencer Dawkins at IETF wrote:
>
>  1. How a sender tunes FEC dynamically - is that automatic, based on
>     FEC mechanisms people are thinking about, or is there work to do
>     there?
>  2. How a sender knows whether to do FEC, retransmission, or both FEC
>     and retransmission, dynamically?
IMHO, each answer depends on which layer you seek to apply FEC and why. 
Adding and adapting FEC at L2 or L3 does not have the same impact than 
at L4 and does not lead to the same adaptive mechanism. Then, adding FEC 
at L4 also depends on whether you are congestion controlled or not, you 
want to stick to TCP-friendliness, your QoS objectives, and many other 
things...
Finally concerning #3, I would say that monitoring the e2e delay would 
give you a good indication to enable FEC or not. If the delay is 
"small", you won't beat ARQ.

Emmanuel

-- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 30 Jul 2019 12:15:54 -0400

On 7/30/2019 10:22 AM, Spencer Dawkins at IETF wrote:
>
> Thanks for giving me the chance to clarify - I really was talking 
> about chartering work, not just chartering a working group, but that 
> wasn't clear from my note. As you said, knowing what the work is, in 
> more detail, will help you and Magnus know what to do next.
>
>  1. In order to "do LOOPS", what already exists, that can be used
>     without changes?
>  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
>
I skimmed the drafts, but might be missing some context still ... LOOPS 
seems like it is intended for "dumb" subnetworks, but could be 
potentially harmful over "smarter" subnetworks.

For satellite links, there is the capability to do per-frame adaptive 
coding and modulation (based on traffic classification). When the lower 
layer offers service tailored for the needs of each packet already, 
LOOPS doing something up above is possibly at odds with this.  It's easy 
to imagine scenarios where this leads to actual performance degradation, 
positive feedback loops, or other problems, so I'm interested in what 
people have done or been thinking about in this regard.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jul 2019 18:30:39 +0200

> I skimmed the drafts, but might be missing some context still ... LOOPS seems like it is intended for “dumb" subnetworks, but could be potentially harmful over "smarter" subnetworks.

If the path segment already tries to be “helpful”, there might indeed be an adverse interaction.  Or the “help” might only be available or effective for certain transport protocols, and LOOPS can still do something useful for those not (yet!) covered (for instance, this could be QUIC).  Also, the “help” might be geared towards close interaction with the transport, and adding a tunnel layer could interfere with this.  So whether running LOOPS on a Sat PEP is useful in any way or even detrimental depends a lot on how up-to-date that PEP is.  Note that the entity running LOOPS may not be the entity running the Sat PEP, so it may not have control over the PEP situation.

Running LOOPS on the path segments from host to Sat and from the Sat to host can remove the need for some costly (in bandwidth and latency) retransmissions on the Sat link itself.  

> For satellite links, there is the capability to do per-frame adaptive coding and modulation (based on traffic classification).  When the lower layer offers service tailored for the needs of each packet already, LOOPS doing something up above is possibly at odds with this.  It’s easy to imagine scenarios where this leads to actual performance degradation, positive feedback loops, or other problems, so I'm interested in what people have done or been thinking about in this regard.

LOOPS is not meant as pixie dust that you sprinkle indiscriminately over your network.
The cost is not entirely trivial and the benefits depend on the characteristics of both the path and the traffic.
You should have a reason to use LOOPS.
See above for some potential reasons to use LOOPS on top of Sat PEPs.

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 30 Jul 2019 12:43:15 -0500

I'm going to be replying to two or three e-mail in this thread, so I'll try
to be coherent over my replies ...

On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit <[email-masked]>
wrote:

> Since most of your questions are related to FEC I copy the nwcrg. See
> <mjm> below
>
> mjm
>
>> > My impression, and Magnus might say I'm insane, was that Magnus is
>> right on the edge of whether this work can be chartered without a second,
>> working group-forming BOF. If the LOOPS community can't live without
>> host-to-node, the community should add it. If the community can make use of
>> LOOPS without host-to-node and add it later, the community might consider
>> whether that reduces the scope of the initial proposed charter enough to
>> help Magnus approve it :-)
>>
> month before IETF 105), but speaking as someone who hasn't been involved in
> depth, I wonder about
>
>    FEC mechanisms people are thinking about, or is there work to do there?
>

So, speaking with no dots because I don't have any, I agree with what
Marie-Jose is saying here, but my understanding is that LOOPS endpoints
might turn LOOPS off completely if local optimizations aren't needed. So
I'm thinking about how a sender makes that decision, and how a sender might
do trade-offs.

I think one point in discussions with Marie-Jose might be that she's
thinking in terms of Technical Specifications (
https://tools.ietf.org/html/rfc2026#section-3.1), which are necessary, but
discussions are making me think that proponents might usefully also think
in terms of Applicability Statements (
https://tools.ietf.org/html/rfc2026#section-3.2), which (quoting)

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.  An AS may specify uses for TSs that are not
   Internet Standards, as discussed in Section 7.

   An AS identifies the relevant TSs and the specific way in which they
   are to be combined, and may also specify particular values or ranges
   of TS parameters or subfunctions of a TS protocol that must be
   implemented.  An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see section
   3.3).

   An AS may describe particular methods of using a TS in a restricted
   "domain of applicability", such as Internet routers, terminal
   servers, Internet systems that interface to Ethernets, or datagram-
   based database servers.

So, if Applicability Statements (also standards-track documents) would be
helpful for LOOPS deployment and operation, the proponents might think
about whether they want to do work in that space.

If decisions about what senders do turn out to be entirely up to the
sender, that's great, but if the proponents want to bound the possible
behaviors of implementations to improve deployment and operation, that
might also be appropriate in BCPs (
https://tools.ietf.org/html/rfc2026#section-5).

>
>    1.
>    How a sender knows that it shouldn't be doing anything, because
Right - so one possibility is publishing work from NWCRG in the IETF
stream, and especially standards-track, with appropriate review by the IETF
community. That could take a lot of forms (RGs and WGs can interact in a
lot of different ways).

> packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG?

See Mirja's note about chartering work, and only chartering working groups
when that's needed. But as you note, the FECFRAME extensions happened in
TSVWG, so that would be a reasonable conversation to have with TSVWG chairs
(and I note that Wes Eddy, who popped up further down in this thread, is a
TSVWG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in an
existing working group, NWCWG could be a plan.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 30 Jul 2019 12:46:14 -0500

Hi, Emmanuel,

On Tue, Jul 30, 2019 at 10:14 AM Emmanuel Lochin <
[email-masked]> wrote:

> Adding and adapting FEC at L2 or L3 does not have the same impact than at
> L4 and does not lead to the same adaptive mechanism. Then, adding FEC at L4
> also depends on whether you are congestion controlled or not, you want to
> stick to TCP-friendliness, your QoS objectives, and many other things...
> give you a good indication to enable FEC or not. If the delay is "small",
> you won't beat ARQ.
>

My understanding from discussions around the LOOPS BOF is that this is
intended to be transport-agnostic, so most likely L3. I haven't heard
anyone talking about L2 LOOPS, but as you note, that depends on the
networks that you're trying to help out.

Thanks for the insight! (I thought that was true, but I'm not an NWC expert
by any stretch)

Spencer

> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http://www.isae-supaero.fr

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 30 Jul 2019 10:55:58 -0700

Well if you to encode IP packets and you have encryption you will get into
the problem of the proposed coding scheme for QUIC that recovers  ALL
packets without knowing what the losses were due to and messing with
congestion control above or not knowing what these packets carry to
determine if they need coding or not or to define the adaptive schemes. Our
solution is before encryption because of that. And as Emmanuel said at
layer 4 you also need to deal with TCP congestion control unless you split
the sessions.

There is a lot of accumulated research, development and implementations out
there :) But ok you are talking to the right people!

mjm

On July 30, 2019 at 1:46:51 PM, Spencer Dawkins at IETF (
[email-masked]) wrote:

Hi, Emmanuel,

Spencer

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 30 Jul 2019 14:21:11 -0400

> See above for some potential reasons to use LOOPS on top of Sat PEPs.

You mention PEP a few times, but I didn't mention PEP, but rather the 
modulation and coding in satellite modems.  The framing and selection of 
MODCOD done by a modem is a lower layer function that's not related to 
PEP techniques at higher layers.

---

From: "Stuart William Card" <[email-masked]>
Date: Tue, 30 Jul 2019 17:56:40 -0400

I realize LOOPS is about neither multicast nor transport, but for likely
useful background, I hope interested people will at least briefly renew
their acquaintance with, inter alia, RFCs 2357, 3048, 3453, 5740, 6584.

> ...
> There is a lot of accumulated research, development and implementations
> out there :) But ok you are talking to the right people!
> ... Marie-Jos Montpetit...

-- 
Stuart W. Card, VP & Chief Scientist
Critical Technologies Inc. (CTI)
<[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 31 Jul 2019 12:19:08 +0200

> On Jul 30, 2019, at 8:21 PM, Wesley Eddy <[email-masked]> wrote:
> 
> You mention PEP a few times, but I didn't mention PEP, but rather the modulation and coding in satellite modems.  The framing and selection of MODCOD done by a modem is a lower layer function that's not related to PEP techniques at higher layers.

Maybe it’s just me, but I don’t understand the potential for negative interactions, positive feedback loops etc:

LOOPS endpoints will only repair losses that they see; whatever L2 can repair wouldn’t be seen by them.
Similarly, whatever repairing LOOPS does wouldn’t be understood by L2 devices - in particular if we’re talking about modems and not PEPs that might try to look a bit deeper into the packets.

Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Wed, 31 Jul 2019 13:17:21 +0100

> On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> I'm going to be replying to two or three e-mail in this thread, so I'll try to be coherent over my replies .... 
> 
> On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>> wrote:
> Since most of your questions are related to FEC I copy the nwcrg. See <mjm> below
> 
> mjm
> 
> On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> Hi, Mirja, 
>> 
>> On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Carsten, hi Spencer,
>> 
>> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> Thanks for giving me the chance to clarify - I really was talking about chartering work, not just chartering a working group, but that wasn't clear from my note. As you said, knowing what the work is, in more detail, will help you and Magnus know what to do next. 
>> 
>> In order to "do LOOPS", what already exists, that can be used without changes?
>> what already exists, but needs to be extended for LOOPS?
>> what needs to be created, because nothing exists that meets the needs?
>>  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?
> 
> So, speaking with no dots because I don't have any, I agree with what Marie-Jose is saying here, but my understanding is that LOOPS endpoints might turn LOOPS off completely if local optimizations aren't needed. So I'm thinking about how a sender makes that decision, and how a sender might do trade-offs. 
> 
> I think one point in discussions with Marie-Jose might be that she's thinking in terms of Technical Specifications (https://tools.ietf.org/html/rfc2026#section-3.1 <https://tools.ietf.org/html/rfc2026#section-3.1>), which are necessary, but discussions are making me think that proponents might usefully also think in terms of Applicability Statements (https://tools.ietf.org/html/rfc2026#section-3.2 <https://tools.ietf.org/html/rfc2026#section-3.2>), which (quoting) 
> 
>    implemented..  An AS also specifies the circumstances in which the use
> So, if Applicability Statements (also standards-track documents) would be helpful for LOOPS deployment and operation, the proponents might think about whether they want to do work in that space. 
> 
> If decisions about what senders do turn out to be entirely up to the sender, that's great, but if the proponents want to bound the possible behaviors of implementations to improve deployment and operation, that might also be appropriate in BCPs (https://tools.ietf.org/html/rfc2026#section-5 <https://tools.ietf.org/html/rfc2026#section-5>).
>  
>> 
> <mjm> Not everyone knows the things but there has been a lot of work in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work was done in a research group not a working group. But real implementations exist in famous “networks". 
> 
> Right - so one possibility is publishing work from NWCRG in the IETF stream, and especially standards-track, with appropriate review by the IETF community. That could take a lot of forms (RGs and WGs can interact in a lot of different ways). 

An IETF WG could have a work item to develop a standards track FEC scheme based on the research previously done in NWCRG, certainly.
> See Mirja's note about chartering work, and only chartering working groups when that's needed. But as you note, the FECFRAME extensions happened in TSVWG, so that would be a reasonable conversation to have with TSVWG chairs (and I note that Wes Eddy, who popped up further down in this thread, is a TSVWG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in an existing working group, NWCWG could be a plan.  

I perhaps misunderstood LOOPS, but I’d assumed that – to the extent is uses FEC and not retransmission – it’d pull in one of the schemes developed in FECFRAME. Has there been any requirements analysis to show if anything further is needed?

This is separate to the question of whether there's work in NWCRG that’s ready to move into IETF for standardisation, of course. 

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 31 Jul 2019 08:56:05 -0400

> Similarly, whatever repairing LOOPS does wouldn’t be understood by L2 devices - in particular if we’re talking about modems and not PEPs that might try to look a bit deeper into the packets.

I think some of it may depend on what LOOPS sees and acts on (aggregate 
of flows or per-flow information), since some flows may be treated 
entirely differently by the lower layer, and may be okay (or even 
desire) different treatment.

In LOOPS tunneling, do different traffic classes wind up in different 
tunnels, or are they all lumped into the same tunnel?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 31 Jul 2019 08:18:32 -0500

Hi, Colin,

On Wed, Jul 31, 2019, 07:36 Colin Perkins <[email-masked]> wrote:

> On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit <
> [email-masked]> wrote:
>
> https://tools.ietf.org/html/rfc2026#section-3.1), which are necessary,
> but discussions are making me think that proponents might usefully also
> think in terms of Applicability Statements (
> An IETF WG could have a work item to develop a standards track FEC scheme
> based on the research previously done in NWCRG, certainly.
>
> I perhaps misunderstood LOOPS, but I’d assumed that – to the extent is
> uses FEC and not retransmission – it’d pull in one of the schemes developed
> in FECFRAME. Has there been any requirements analysis to show if anything
> further is needed?
>

That's the analysis that I'm suggesting the proponents work on now. I
didn't talk to all the proponents in Montreal, but at least a couple were
pretty sure they wanted to use FEC, but were still figuring out details on
that usage.

Marie-Jose and some other nice people from NWCRG are providing pointers to
help with that analysis. For which, I'm grateful. I was the responsible AD
for the recent sliding window FECFRAME extensions that migrated through
TSVWG, and I understand FECFRAME at a 10,000-meter level, but the
proponents (and interested parties) need to work through the next level of
details.

This is separate to the question of whether there's work in NWCRG that’s
> ready to move into IETF for standardisation, of course.
>

The nice thing about the existing relationship between NWCRG and TSVWG is
that if there's more stuff from NWCRG that's ready to standardize in the
IETF, we know how to do that, and Wes Eddy (one of the TSVWG co-chairs) is
already helping with congestion discussion on this mailing list.

I think the non-working group-forming BOF did a good job at flushing out
the questions and the resources needed to answer them. Thanks, Magnus and
Mirja, for making that easy.

Spencer

Colin

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jul 2019 15:33:03 +0200

On Jul 31, 2019, at 14:56, Wesley Eddy <[email-masked]> wrote:
> 
> In LOOPS tunneling, do different traffic classes wind up in different tunnels, or are they all lumped into the same tunnel?

That depends entirely on the tunnel setup, which is out of scope of LOOPS itself.

A network operator typically will select the traffic that will receive the (relatively speaking, more expensive) LOOPS treatment.  In a host-to-node scenario (that was stressed to be important at the BOF), there may be sufficient explicit configuration to do this as well, or it may be a catch-all.

So LOOPS is meant to operate on an aggregate, not just a finely sliced piece of traffic (or a single flow).

I’m not aware of proposals to have the LOOPS protocol itself handle different classes differently.  However, the actual retransmission decision has some room for adding (unilateral) secret sauce, and that may include looking at the class.

Grüße, Carsten

---

From: <[email-masked]>
Date: Wed, 31 Jul 2019 13:55:19 +0000

Hi Spencer, all,

I would restrict the host-to-network interaction to the minimum (read ECN) in the initial scope of the this proposed work. FWIW, below a tentative scope we included in the use-cases I-D:

=========
   investigate to what extent a network-assisted approach can contribute
   to increase the overall perceived quality of experience in specific
   situations (e.g., Sections 3.5<https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#section-3.5> and 3.6<https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#section-3.6> of [RFC8517<https://tools.ietf.org/html/rfc8517>]) without
   requiring access to internal transport primitives.  The rationale
   beneath this approach is that some information (loss detection,
   better visibility on available paths and their characteristics, etc.)
   can be used to trigger local actions while avoiding as much as
   possible undesired side effects (e.g., expose a behavior that would
   be interpreted by an endpoint as an anomaly (corrupt data) and which
   would lead to exacerbate end-to-end recovery.  Such local actions
   would have a faster effect (e.g., faster recovery, used multiple
   paths simultaneously).

   To that aim, the work is structured into two (2) phased stages:

   o  Stage 1: Network-assisted optimization.  This one assumes that
      optimizations (e.g., support latency-sensitive applications) can
      be implemented at the network without requiring defining new
      interaction with the endpoint.  Existing tools such as ECN will be
      used.  Some of these optimizations may be valuable in deployments
      where communications are established over paths that are not
      exposing the same performance characteristics.

   o  Stage 2: Collaborative networking optimization.  This one requires
      more interaction between the network and an endpoint to implement
      coordinated and more surgical network-assisted optimizations based
      on information/instructions shared by an endpoint or sharing
      locally-visible information with endpoint for better and faster
      recovery.

   Effort related to the
   second stage is out of scope of the initial planned work.
   Nevertheless, future work will be planned once progress is
   (hopefully) made on the first stage.
=====

Cheers,
Med

De : LOOPS [mailto:[email-masked]] De la part de Spencer Dawkins at IETF
Envoyé : jeudi 25 juillet 2019 20:59
À : Carsten Bormann
Cc : Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind; [email-masked]; Suresh Krishnan
Objet : Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Hi Marie-José,

Communication is good, but one thing I mentioned in my summary of my chat with the ADs was

  *   Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D
So, it's reasonable for the LOOPS community to consider adding host-to-node, but it's worth checking whether this would expand the scope of the requested charter, and whether excluding host-to-node makes the initial work easier to complete.

Best wishes,

Spencer

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 31 Jul 2019 10:02:25 -0400

This is a very wide scope that covers many existing groups. Can you focus
on a narrower scope?

On July 31, 2019 at 9:55:37 AM, [email-masked] (
[email-masked]) wrote:

Hi Spencer, all,

I would restrict the host-to-network interaction to the minimum (read ECN)
in the initial scope of the this proposed work. FWIW, below a tentative
scope we included in the use-cases I-D:

=========

   situations (e.g., Sections 3.5
<https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#section-3.5>
and 3.6
<https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#section-3.6>
of [RFC8517 <https://tools.ietf.org/html/rfc8517>]) without

   paths simultaneously).

      recovery.

   Effort related to the

=====

Cheers,

Med

*De :* LOOPS [mailto:[email-masked]] *De la part de* Spencer
Dawkins at IETF
*Envoyé :* jeudi 25 juillet 2019 20:59
*À :* Carsten Bormann
*Cc :* Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind;
[email-masked]; Suresh Krishnan
*Objet :* Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

Hi Marie-José,

Best wishes,

Spencer

---

From: <[email-masked]>
Date: Wed, 31 Jul 2019 14:06:10 +0000

Re-,

Local recovery/local measurement isn’t specific enough?

Cheers,
Med

De : Marie-Jose Montpetit [mailto:[email-masked]]
Envoyé : mercredi 31 juillet 2019 16:02
À : BOUCADAIR Mohamed TGI/OLN; Spencer Dawkins at IETF
Cc : Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; [email-masked]
Objet : Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

This is a very wide scope that covers many existing groups. Can you focus on a narrower scope?

On July 31, 2019 at 9:55:37 AM, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:
Hi Spencer, all,

=========

   Effort related to the

Cheers,
Med

De : LOOPS [mailto:[email-masked]<mailto:[email-masked]>] De la part de Spencer Dawkins at IETF
Envoyé : jeudi 25 juillet 2019 20:59
À : Carsten Bormann
Cc : Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind; [email-masked]<mailto:[email-masked]>; Suresh Krishnan
Objet : Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

Hi Marie-José,

Best wishes,

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 31 Jul 2019 15:14:42 +0100

Agree - thanks, Spencer.
Colin

> On 31 Jul 2019, at 14:18, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Colin,
> 
> On Wed, Jul 31, 2019, 07:36 Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
>> On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> That's the analysis that I'm suggesting the proponents work on now. I didn't talk to all the proponents in Montreal, but at least a couple were pretty sure they wanted to use FEC, but were still figuring out details on that usage. 
> 
> Marie-Jose and some other nice people from NWCRG are providing pointers to help with that analysis. For which, I'm grateful. I was the responsible AD for the recent sliding window FECFRAME extensions that migrated through TSVWG, and I understand FECFRAME at a 10,000-meter level, but the proponents (and interested parties) need to work through the next level of details.
> 
> The nice thing about the existing relationship between NWCRG and TSVWG is that if there's more stuff from NWCRG that's ready to standardize in the IETF, we know how to do that, and Wes Eddy (one of the TSVWG co-chairs) is already helping with congestion discussion on this mailing list.
> 
> I think the non-working group-forming BOF did a good job at flushing out the questions and the resources needed to answer them. Thanks, Magnus and Mirja, for making that easy.
> 
> Spencer
> 
> Colin
> 
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jul 2019 16:18:18 +0200

Hi Marie-José,

the scope of LOOPS as we went into IETF105 is written up at

I’m not going to paraphrase this here, but the main elements are:

* Local recovery between cooperating LOOPS nodes that do not span the entire end-to-end path
* Related measurement mechanisms
* Congestion feedback that doesn’t cause the loss recovery to derail the end-to-end congestion control
* Scope restriction: No involvement of end hosts needed
* Scope restriction: Don’t look, don’t touch
* Scope restriction: Setup via controller model
* Technical approach: Don’t invent another tunnel encapsulation, use existing ones (probably more than one) where they make sense

The host-to-node discussion we had in IETF105 may be a bit confusing.  This was not about changing the transport protocols at the hosts so they work better with in-network friends (this could also be done, but would not be LOOPS as proposed).  This is about using e.g. a VPN layer in a host as one of the two cooperating LOOPS nodes.  So the actual protocol will be essentially the same, but there may be a modified setup model.

The other need for modification that became apparent during IETF105 is that we probably should ship a retransmission-only version of the protocol before nailing down all the FEC-related parts.

Grüße, Carsten

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 31 Jul 2019 12:02:00 -0500

I had read the charter :)

And local/recovery and measurements is not very specific :) But ok I guess
it will evolve.

And as regard retransmission I am looking forward to see the results vs. a
true erasure recovery mechanism in terms of efficiency and complexity.

mjm

On July 31, 2019 at 10:06:12 AM, [email-masked] (
[email-masked]) wrote:

Re-,

Cheers,

Med

*De :* Marie-Jose Montpetit [mailto:[email-masked]]
*Envoyé :* mercredi 31 juillet 2019 16:02
*À :* BOUCADAIR Mohamed TGI/OLN; Spencer Dawkins at IETF
*Cc :* Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; [email-masked]
*Objet :* Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

[email-masked]

Hi Spencer, all,

=========

   paths simultaneously).

      recovery.

   Effort related to the

=====

Cheers,

Med

Hi Marie-José,

Best wishes,

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Thu, 1 Aug 2019 00:18:20 +0200

Hi,

About the retransmission vs FEC (erasure coding) point, I don’t think anyone would suggest a comparison?
Isn’t it clear to everybody that FEC is strictly better than retransmission if the packet loss ratio is known and it’s possible to add forward information?
(else, why would FEC exist?)

But I agree with Carsten that we should probably do retransmission-only first - it makes things simpler.
For one, a pure retransmission-based mechanism can work without adding any forward information. And, when one *can* add forward information, FEC is an obvious “++" that shouldn’t change anything about the architecture but simply make things better.

Just my 2c

Cheers,
Michael

> On Jul 31, 2019, at 7:02 PM, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> And local/recovery and measurements is not very specific :) But ok I guess it will evolve.
> 
> And as regard retransmission I am looking forward to see the results vs. a true erasure recovery mechanism in terms of efficiency and complexity..
> 
> mjm
> 
> On July 31, 2019 at 10:06:12 AM, [email-masked] <mailto:[email-masked]> ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> Re-,
>> 
>>  
>> De : Marie-Jose Montpetit [mailto:[email-masked] <mailto:[email-masked]>] 
>> Cc : Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; [email-masked] <mailto:[email-masked]>
>> On July 31, 2019 at 9:55:37 AM, [email-masked] <mailto:[email-masked]> ([email-masked] <mailto:[email-masked]>) wrote:
>> 
>> Hi Spencer, all,
>> 
>>  
>>    situations (e.g., Sections 3.5 <https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#section-3.5> and 3.6 <https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#section-3.6> of [RFC8517 <https://tools.ietf.org/html/rfc8517>]) without
>> 
>>    would lead to exacerbate end-to-end recovery..  Such local actions
>> 
>> De : LOOPS [mailto:[email-masked] <mailto:[email-masked]>] De la part de Spencer Dawkins at IETF
>> Cc : Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind; [email-masked] <mailto:[email-masked]>; Suresh Krishnan
>> On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> https://github.com/loops-wg/charter <https://github.com/loops-wg/charter>
>> 
>> Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D 
>> My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it.. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) 
>> 
>>  
>> Best wishes, 
>> 
>>  
>> Spencer
>> 
>> -- 
>> LOOPS mailing list 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/loops <https://www.ietf.org/mailman/listinfo/loops>-- 
> LOOPS mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Aug 2019 01:11:33 +0200

On Aug 1, 2019, at 00:18, Michael Welzl <[email-masked]> wrote:
> 
> if the packet loss ratio is known

Conversely, retransmission can be better to handle random, bursty losses.
(For a definition of “better”, which may depend on your needs.)

But more importantly, for retransmission, the ingress node needs to store copies of packets for a while (and retransmit from this cache), and the egress node needs to send ACKs.  This is much less work per packet than doing FEC, which needs processing of the contents of each packet.  So nodes may be able to do retransmission LOOPS at a higher rate than they would be able to do FEC LOOPS.

Grüße, Carsten

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 31 Jul 2019 18:28:04 -0500

Actually in FEC you do not process every packet. In what is called
“systematic mode” you send all the packets in the buffer (window) followed
by the coded packet(s). If everything goes well you never process anything.
And if something is lost then you use the recovery packets.

mjm

On July 31, 2019 at 7:11:41 PM, Carsten Bormann ([email-masked]) wrote:

But more importantly, for retransmission, the ingress node needs to store
copies of packets for a while (and retransmit from this cache), and the
egress node needs to send ACKs. This is much less work per packet than
doing FEC, which needs processing of the contents of each packet. So nodes
may be able to do retransmission LOOPS at a higher rate than they would be
able to do FEC LOOPS.

Grüße, Carsten