[Plus] Status of PLUS

Brian Trammell (IETF) <ietf@trammell.ch> Tue, 28 February 2017 22:56 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: plus@ietfa.amsl.com
Delivered-To: plus@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EC7A7129415 for <plus@ietfa.amsl.com>; Tue, 28 Feb 2017 14:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id O0734vtnXYrM for <plus@ietfa.amsl.com>; Tue, 28 Feb 2017 14:56:40 -0800 (PST)
Received: from gozo.iway.ch (gozo.iway.ch []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6940012978C for <plus@ietf.org>; Tue, 28 Feb 2017 14:56:37 -0800 (PST)
Received: from gozo.iway.ch (localhost []) by localhost (Postfix) with ESMTP id 10E1A340E5F for <plus@ietf.org>; Tue, 28 Feb 2017 23:56:36 +0100 (CET)
Received: from localhost (localhost []) by localhost (ACF/22542.13620); Tue, 28 Feb 2017 23:56:36 +0100 (CET)
Received: from switchplus-mail.ch (switchplus-mail.ch []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for <plus@ietf.org>; Tue, 28 Feb 2017 23:56:35 +0100 (CET)
Received: from lukmanier.dynamic.ucsd.edu (account ietf@trammell.ch [] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 9994917 for plus@ietf.org; Tue, 28 Feb 2017 23:56:35 +0100
From: Brian Trammell (IETF) <ietf@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_B1987338-D9AE-4372-B018-BD5343E583C1"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <E5F420F7-6B91-4E00-A434-A2A9B77DA3C8@trammell.ch>
References: <28F27305-3F58-4091-857C-4BD4BEE8093C@trammell.ch>
To: plus@ietf.org
Date: Tue, 28 Feb 2017 14:56:32 -0800
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/xzRUTUXpZgD73KuPIh0FYAlBcmE>
Subject: [Plus] Status of PLUS
X-BeenThere: plus@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." <plus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plus>, <mailto:plus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plus/>
List-Post: <mailto:plus@ietf.org>
List-Help: <mailto:plus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plus>, <mailto:plus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2017 22:56:55 -0000

Hi, Lin, all,

Circling back on these points...

> On 14 Feb 2017, at 22:38, Lin Han <Lin.Han@huawei.com> wrote:
> Hello, all
> Just signed up this list, I knew PLUS has been concluded unfortunately.

In the sense that the BoF failed to come to consensus that a working group could be formed with the presented scope, due to questions about the privacy risk / utility tradeoff of a generalized solution to the problem of replacing implicit interference by path elements with explicit communication, yes... I would not yet say we've come to a "conclusion" yet, though.

> The idea of PLUS is very useful for the transportation improvement for some applications that the traditional transport could not support properly.
> Want to see what is the plan for the group ?

Stepping back, there are three things I think we wanted out of PLUS:

(1) Providing basic measurability and state maintenance for transport protocols with encrypted headers, and doing it once. The basic header in draft-trammell-plus-spec does this. You could get the same effect by adding the same information to some variants of the QUIC public header. In any case, without a common basic header, the measurability and statefulness of new transport protocols will have to be considered by each new transport protocol. draft-kuehlewind-plus-appman is an initial applicability and manageability statement for QUIC, the manageability section of which will discuss these issues specific to QUIC.

(2) Adding (very) small amounts of information to packets to give advisory signals to path elements on how the application would prefer they be handled. Kind of like DSCP, but with end-to-end integrity protection. The Basic Header in draft-trammell-plus-spec does this for two bits: L for signaling transport-layer loss insensitivity, and R for signaling transport-layer reordering insensitivity. One could add more to the extended header at additional cost. Here, the questions (raised at the ACCORD BoF for the loss insensitivity bit) are, as I understand them, about utility for cost: i.e., 1% better aggregate throughput is not worth twenty additional header bytes per packet. FWIW we're doing some experiments with in-network handling of the L bit this year.

(3) Building a generalized, transport-protocol-independent facility for communicating arbitrary information from endpoints to the path, or from the path to endpoints. This is where SPUD started off, and this is what we showed can work with endpoint integrity protection in draft-trammell-plus-abstract-mech. This is also where most of the controversy in the PLUS BoF came from. What I took away from the feedback at the PLUS BoF is that we need to have a much better idea of the restricted vocabulary we'd use with such a thing, how these restrictions can be enforced, and the incremental benefits of that vocabulary. There’s certainly room for more research on these points.



> Regards
> Lin
> _______________________________________________
> Plus mailing list
> Plus@ietf.org
> https://www.ietf.org/mailman/listinfo/plus