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

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

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 <
[e-mail]> wrote:

> 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-Jose
>    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
>