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

Carsten Bormann <cabo@tzi.org> Wed, 31 July 2019 14:18 UTC

Return-Path: <cabo@tzi.org>
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 723DC12006D for <loops@ietfa.amsl.com>; Wed, 31 Jul 2019 07:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 9bb3IqgM7GMj for <loops@ietfa.amsl.com>; Wed, 31 Jul 2019 07:18:20 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4896612004F for <loops@ietf.org>; Wed, 31 Jul 2019 07:18:20 -0700 (PDT)
Received: from client-0158.vpn.uni-bremen.de (client-0158.vpn.uni-bremen.de [134.102.107.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45zFrp5mJ1z10Xl; Wed, 31 Jul 2019 16:18:18 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAPjWiCTo+TjgJ97TTyY3yF=9BAiEyqnyDNbaHjXdqzW5h3JjAw@mail.gmail.com>
Date: Wed, 31 Jul 2019 16:18:18 +0200
Cc: mohamed.boucadair@orange.com, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Suresh Krishnan <suresh@kaloom.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, "loops@ietf.org" <loops@ietf.org>
X-Mao-Original-Outgoing-Id: 586275490.653143-3df77ee1bcac8e2f10fa8e99c37f1d41
Content-Transfer-Encoding: quoted-printable
Message-Id: <C38A3235-FDE1-4C78-9306-CF97960774AE@tzi.org>
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>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/27wDF_yquE1yqiEMpRDbjne9-Ko>
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 14:18:22 -0000

On Jul 31, 2019, at 16:02, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
> 
> This is a very wide scope that covers many existing groups. Can you focus on a narrower scope?

Hi Marie-José,

the scope of LOOPS as we went into IETF105 is written up at

https://github.com/loops-wg/charter

I’m not going to paraphrase this here, but the main elements are:

* Local recovery between cooperating LOOPS nodes that do not span the entire end-to-end path
* Related measurement mechanisms
* Congestion feedback that doesn’t cause the loss recovery to derail the end-to-end congestion control
* Scope restriction: No involvement of end hosts needed
* Scope restriction: Don’t look, don’t touch
* Scope restriction: Setup via controller model
* Technical approach: Don’t invent another tunnel encapsulation, use existing ones (probably more than one) where they make sense

The host-to-node discussion we had in IETF105 may be a bit confusing.  This was not about changing the transport protocols at the hosts so they work better with in-network friends (this could also be done, but would not be LOOPS as proposed).  This is about using e.g. a VPN layer in a host as one of the two cooperating LOOPS nodes.  So the actual protocol will be essentially the same, but there may be a modified setup model.

The other need for modification that became apparent during IETF105 is that we probably should ship a retransmission-only version of the protocol before nailing down all the FEC-related parts.

Grüße, Carsten