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

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

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