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

Carsten Bormann <cabo@tzi.org> Wed, 31 July 2019 13:33 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 54C77120020 for <loops@ietfa.amsl.com>; Wed, 31 Jul 2019 06:33:08 -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 RBIAa7qhCIHt for <loops@ietfa.amsl.com>; Wed, 31 Jul 2019 06:33:06 -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 545AB120018 for <loops@ietf.org>; Wed, 31 Jul 2019 06:33:06 -0700 (PDT)
Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (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 45zDrc3KmYzysD; Wed, 31 Jul 2019 15:33:04 +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: <3d808274-38d7-98eb-42b7-875f2f840f29@mti-systems.com>
Date: Wed, 31 Jul 2019 15:33:03 +0200
Cc: Michael Welzl <michawe@ifi.uio.no>, loops@ietf.org
X-Mao-Original-Outgoing-Id: 586272777.395498-14b8599b1f46a8c38333c98677589103
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3E03616-F773-41B0-8D11-665F65963DFF@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> <A4576796-AACA-4BE1-9EF8-9422E1BAB9F3@kuehlewind.net> <CAKKJt-dCeJVhofU8eO=TXu6CVez5g9ZTdLnp206gx6X3YTx9tA@mail.gmail.com> <c8c5332d-a41d-7750-5605-285b9c449b8a@mti-systems.com> <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com> <579BEAE9-23E2-4E4F-BA26-6FA7F7C9CF6D@ifi.uio.no> <3d808274-38d7-98eb-42b7-875f2f840f29@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/jHGMqapUjAJPliDo_xbHVVcu-yY>
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 13:33:08 -0000

On Jul 31, 2019, at 14:56, Wesley Eddy <wes@mti-systems.com> wrote:
> 
> In LOOPS tunneling, do different traffic classes wind up in different tunnels, or are they all lumped into the same tunnel?

That depends entirely on the tunnel setup, which is out of scope of LOOPS itself.

A network operator typically will select the traffic that will receive the (relatively speaking, more expensive) LOOPS treatment.  In a host-to-node scenario (that was stressed to be important at the BOF), there may be sufficient explicit configuration to do this as well, or it may be a catch-all.

So LOOPS is meant to operate on an aggregate, not just a finely sliced piece of traffic (or a single flow).

I’m not aware of proposals to have the LOOPS protocol itself handle different classes differently.  However, the actual retransmission decision has some room for adding (unilateral) secret sauce, and that may include looking at the class.

Grüße, Carsten