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

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

Hi, Marie-Jose,

On Wed, Jul 24, 2019 at 6:17 PM Marie-Jose Montpetit <[e-mail]>
wrote:

> Standardisation of what? The architecture? The protocols (beware there is
> 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


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