Re: wrt quic, plus, and taps?

Brian Trammell <ietf@trammell.ch> Wed, 20 July 2016 21:32 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E448912D15F for <ietf@ietfa.amsl.com>; Wed, 20 Jul 2016 14:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-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 GUhm2SCSDkgo for <ietf@ietfa.amsl.com>; Wed, 20 Jul 2016 14:32:57 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8212B05D for <ietf@ietf.org>; Wed, 20 Jul 2016 14:32:57 -0700 (PDT)
Received: from surfer-172-29-124-241-hotspot.internet-for-guests.com (unknown [62.214.2.210]) by trammell.ch (Postfix) with ESMTPSA id 50EA21A0348; Wed, 20 Jul 2016 23:32:26 +0200 (CEST)
Subject: Re: wrt quic, plus, and taps?
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_47AE5F4D-DB90-4628-A815-97AA9CA56B34"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <20160720042205.Horde.mtiNIrCugguHu1koXROF-c9@box514.bluehost.com>
Date: Wed, 20 Jul 2016 23:32:25 +0200
Message-Id: <6A8E0DC2-B8E4-43D0-81FF-C3FB7780B468@trammell.ch>
References: <20160720042205.Horde.mtiNIrCugguHu1koXROF-c9@box514.bluehost.com>
To: jeff.hodges@kingsmountain.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vL950Y2P4Dm_hMdAUYe14So2ClU>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2016 21:33:00 -0000

hi Jeff,

Thanks for the question. I'll try to answer it succinctly.

QUIC is a transport protocol that runs over UDP, that encrypts almost all of its headers and all of its payload. It does this for privacy and security for the applications running over it, and to separate what the path needs to see from what the endpoints need to see, in order to enable relatively rapid evolution of the protocol. It is presently focused on supporting HTTP/2 as an application, but should be usable for many other applications with broadly similar requirements.

PLUS is a mechanism for building transport protocols with encrypted headers and payload over UDP, to separate what the path needs to see from what the endpoints need to see, in order enable the relatively rapid deployment of multiple transport protocols with a common surface exposed to devices on path. It also supports (optional) facilities for explicit cooperation between applications or transports and devices on path. You'll note these descriptions are quite similar: if PLUS had been built two years ago, it would probably make sense to build QUIC over PLUS. Because QUIC is designed to be easily versionable, future versions of QUIC could run over PLUS. Since QUIC will have to deal with many of the same issues PLUS aims to solve with respect to broadly deployable transports over UDP, deployment and implementation experience with QUIC will definitely inform the detailed design of PLUS.

These are two separate working groups because the focus of PLUS really is on explicit cooperation with on-path devices (under endpoint control) as an architectural pattern, and QUIC on a specific transport protocol.

TAPS is an effort to define a set of "transport services" and the properties thereof, and to support runtime selection of transport protocols based on application requirements in terms of these transport services and on-path support for these protocols. It generalizes the fallback mechanism QUIC uses to select among multiple protocols. QUIC provides another protocol to the set for TAPS to select from. PLUS provides a way to deploy other, future protocols for TAPS to select from.

Hope this helps, cheers,

Brian (no hats)

> On 20 Jul 2016, at 12:22, jeff.hodges@kingsmountain.com wrote:
> 
> perhaps someone can explain at some point what the salient intersection(s) and difference(s) are between:  quic, plus, and taps ?
> 
> thanks,
> 
> =JeffH
> 
>