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

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<mailto:mariejose@mjmontpetit.com>
mariejo@mit.edu<mailto:mariejo@mit.edu>

On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> (mohamed.boucadair@orange.com<mailto: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<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<mailto: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<mailto:cabo@tzi.org>> wrote:
On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <marie@mjmontpetit.com<mailto: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<mailto:LOOPS@ietf.org>
https://www.ietf.org/mailman/listinfo/loops