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

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

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com
mariejo@mit.edu

On July 31, 2019 at 10:06:12 AM, mohamed.boucadair@orange.com (
mohamed.boucadair@orange.com) wrote:

Re-,

Local recovery/local measurement isn’t specific enough?

Cheers,

Med

*De :* Marie-Jose Montpetit [mailto:marie@mjmontpetit.com]
*Envoyé :* mercredi 31 juillet 2019 16:02
*À :* BOUCADAIR Mohamed TGI/OLN; Spencer Dawkins at IETF
*Cc :* Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; loops@ietf.org
*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?

Marie-José Montpetit, Ph.D.

Research Affiliate, MIT Media Laboratory

mariejose@mjmontpetit.com

mariejo@mit.edu

On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com (
mohamed.boucadair@orange.com) 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:

=========

   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:loops-bounces@ietf.org] *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;
loops@ietf.org; Suresh Krishnan
*Objet :* Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

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

On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <cabo@tzi.org> wrote:

On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <marie@mjmontpetit.com>
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.

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.

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
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops