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

[Marie-Jose Montpetit <[e-mail]>]

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

mjm

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

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

> 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
>>
> --
> LOOPS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/loops
>