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

Michael Welzl <michawe@ifi.uio.no> Wed, 31 July 2019 22:18 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211412001E for <loops@ietfa.amsl.com>; Wed, 31 Jul 2019 15:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w_3AVdGz1cB for <loops@ietfa.amsl.com>; Wed, 31 Jul 2019 15:18:36 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931F9120046 for <loops@ietf.org>; Wed, 31 Jul 2019 15:18:35 -0700 (PDT)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hswvU-0005Gf-0q; Thu, 01 Aug 2019 00:18:28 +0200
Received: from 178.115.130.27.wireless.dyn.drei.com ([178.115.130.27] helo=[192.168.1.162]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from <michawe@ifi.uio.no>) id 1hswvQ-000EGr-KF; Thu, 01 Aug 2019 00:18:27 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <EDE4C911-86A2-4347-B623-4B0CEF26C5D4@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_23746E50-1248-4942-97F7-AFE17F78500D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 01 Aug 2019 00:18:20 +0200
In-Reply-To: <CAPjWiCQpZ_60XO8+5dFC4Gp8Jh=bjpQSOnVE85LZi=OtjwP=Uw@mail.gmail.com>
Cc: mohamed.boucadair@orange.com, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, Suresh Krishnan <suresh@kaloom.com>, "loops@ietf.org" <loops@ietf.org>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
References: <CAKKJt-eRGJe+9PtEC7xgFz+HA0zsr_sR0NUgKRmJ-P5Q3XBg-A@mail.gmail.com> <CAPjWiCSbPioTHkYBpX73qxzO=H1sJDZpCMCKzBKoU4rZLLhwMQ@mail.gmail.com> <E6659E42-D6D7-4033-B4D6-9305823063D2@tzi.org> <CAKKJt-c24RdPyZRoK-B6fXuN0xABUsU=p7Y6UFwAcENfjE3oOQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAPjWiCTo+TjgJ97TTyY3yF=9BAiEyqnyDNbaHjXdqzW5h3JjAw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAPjWiCQpZ_60XO8+5dFC4Gp8Jh=bjpQSOnVE85LZi=OtjwP=Uw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 178.115.130.27 is neither permitted nor denied by domain of ifi.uio.no) client-ip=178.115.130.27; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.162];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 115C52AAEDBAF633DFBEF7DCBEE74A5351B778C7
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/0Hg_UNEc3PfB5bbZz1cIijLxlF4>
Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 22:18:40 -0000

Hi,

About the retransmission vs FEC (erasure coding) point, I don’t think anyone would suggest a comparison?
Isn’t it clear to everybody that FEC is strictly better than retransmission if the packet loss ratio is known and it’s possible to add forward information?
(else, why would FEC exist?)

But I agree with Carsten that we should probably do retransmission-only first - it makes things simpler.
For one, a pure retransmission-based mechanism can work without adding any forward information. And, when one *can* add forward information, FEC is an obvious “++" that shouldn’t change anything about the architecture but simply make things better.

Just my 2c

Cheers,
Michael


> On Jul 31, 2019, at 7:02 PM, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
> 
> 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 <mailto:mariejose@mjmontpetit.com>
> mariejo@mit.edu <mailto:mariejo@mit.edu>
> On July 31, 2019 at 10:06:12 AM, mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> (mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>) wrote:
> 
>> Re-,
>> 
>>  
>> Local recovery/local measurement isn’t specific enough?
>> 
>>  
>> Cheers,
>> 
>> Med
>> 
>>  
>> De : Marie-Jose Montpetit [mailto:marie@mjmontpetit.com <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 <mailto: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 <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 <https://www.ietf.org/mailman/listinfo/loops>-- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops