Re: QUIC - Our schedule and scope
Bernard Aboba <bernard.aboba@gmail.com> Wed, 01 November 2017 07:16 UTC
Return-Path: <bernard.aboba@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7800913FE40 for <quic@ietfa.amsl.com>; Wed, 1 Nov 2017 00:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 67WBFYZ8yMi4 for <quic@ietfa.amsl.com>; Wed, 1 Nov 2017 00:16:33 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE6113F772 for <quic@ietf.org>; Wed, 1 Nov 2017 00:16:33 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id b11so936453uae.12 for <quic@ietf.org>; Wed, 01 Nov 2017 00:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vC8R0QpZGBCkQQiVw7wQykgeqrY86pO/GPZzl5TXSZg=; b=WC7SxHDvhE7jYWLtno3W0rTej7bP4aeQunwO8a93BWmsghvi9DQIyzTRXFzz8m/IJS bMloLy0DoLq1LduKLCklue+kUEhexEz5uEHEa3jvFWK+bV6M4cqTO678hCTfEXtTZdon opm862zgMe19SMhcdqDSisituWlRrjjGm0Gp3agOr5nssmkwSBZeE+t6mNVQKlZkA/nY p9t3MEtZz5P0qsxV7+L21Ex5IlFUnLCkJchs6xKByzOcRhiLtEzB49V/7jfsPAbEfx3B 1KcksbsHXJ/LXO5G0Ia8DGzuXwYhLQATGpdE3e2nZEWIjmXCgYvp/P4krJwMBDgdsLTB k9wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vC8R0QpZGBCkQQiVw7wQykgeqrY86pO/GPZzl5TXSZg=; b=YzWILh5gjOlulmyT4+lgfz8aNwWk06ASpcudVaOKnqzD/FtXN9X4E4Jdg+wblAGOq1 71Sj6sS60C7rNLbPqyQmeM/otZyP7lKZtMEp3FwmwU5VJ2/x0wSBKa6VLnwCfrYGfJzM veL2ZweYLduDPl/lf4b/iy6ArZkHPCxHVSxeAd5QYiBVPJYAUpEw5ACHAuVznLcbx8RO 3q7+gfSme5AkrVofHcM0OvzaXHQygfTpxxLar5bWLTykeSGJlyXYbmFRlXlWYGqIPHT/ 2aRPRaKR6mfss5MEglcdAV/JpqgJk2rn9Kv1yusb5VVaB36Z6QEBRVItUUndMx7Mw8Zj hhcA==
X-Gm-Message-State: AMCzsaWD+wVcm6zq1LWDQnvit3zsGk1UtUWUFhtoQxoxpKUcctX3BzEK 3R0306ekRmjO8p2OFyr8bRldknPpGABRS73mEcA=
X-Google-Smtp-Source: ABhQp+Q9vmobUeymST8ySb22TbuQuJPjMm5Qo4bEV52KJlc7b3ckQqiPiVe7dCOhDdiYSBsVRh76An+E/ICv8+/Imns=
X-Received: by 10.176.81.68 with SMTP id f4mr3400472uaa.52.1509520591958; Wed, 01 Nov 2017 00:16:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Wed, 1 Nov 2017 00:16:11 -0700 (PDT)
In-Reply-To: <EF177987-B730-4FDB-898D-8036F6B95B28@csperkins.org>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <AE0180A5-7577-44C0-8FF6-0AFD1E3B9E00@trammell.ch> <EF177987-B730-4FDB-898D-8036F6B95B28@csperkins.org>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 01 Nov 2017 00:16:11 -0700
Message-ID: <CAOW+2dvsm8yTHk8BarRDDgSGnO9gq8=kFJSV2zYqSSzRwdHEdQ@mail.gmail.com>
Subject: Re: QUIC - Our schedule and scope
To: Colin Perkins <csp@csperkins.org>
Cc: "Brian Trammell (IETF)" <ietf@trammell.ch>, Mark Nottingham <mnot@mnot.net>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@netapp.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c191318aa3954055ce6a61c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cfUqi8zUND7gfy0UWnBE40GYwuE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2017 07:16:35 -0000
Colin Perkins said: "I do think that peer-to-peer uses of QUIC need attention pre-V1, if they’re to be supported cleanly. At minimum, we need to arrange the QUIC headers to easily demultiplex with STUN on the same UDP port, otherwise we’ll end-up re-inventing STUN within QUIC. Focussing solely on HTTP is going to make this difficult. See draft-aboba-avtcore-quic-multiplexing-00 for more discussion." [BA] Peer-to-peer uses of QUIC are under development, and are quite likely to be deployed in advance of a v2 specification. As the multiplexing draft makes clear, there is an alternative (a single octet shim) that enables de-multiplexing of QUIC without modification (or even consideration) of QUIC headers. So while native demultiplexing QUIC headers from STUN might be preferred, this probably can't be characterized as a "must have". Given that some of the most popular peer-to-peer uses involve unreliable data exchange (e.g. in games), support for that is a basic requirement. A "quick and dirty" approach would be to utilize a QUIC stream for each message, while setting a timer so as to approximate a data channel's maxPacketLifetime parameter. A more thorough solution would be to support unreliable QUIC streams natively, allowing maxPacketLifetime or maxRetransmits to be enforced on a per-packet basis, mimicing the behavior of an unreliable RTCDataChannel running over SCTP/DTLS/UDP. The problem with the "quick and dirty" approach is that many peer-to-peer data exchange developers are obsessed with latency and therefore may prefer no retransmissions at all. This could lead to widespread deployment of draft-tiesel-quic-unreliable-streams prior to standardization. On Sun, Oct 29, 2017 at 11:08 AM, Colin Perkins <csp@csperkins.org> wrote: > > > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <ietf@trammell.ch> > wrote: > > > > hi Mark, all, > > > > Broadly, I support Patrick's intepretation here. I'll point out that > there seems to be some inconsistency between two points below: > > > >> On 27 Oct 2017, at 08:26, Mark Nottingham <mnot@mnot.net> wrote: > >> > >> 2) V1 of QUIC should *only* address the use case of HTTP. > > > > and > > > >> * V1 will need to document the "invariants" of QUIC -- i.e., the parts > on the wire that will not change -- to allow other use cases to be > addressed by V2 and beyond. > > > > That QUIC's handshake, pre-version-negotiation wire image, and > ossification-prevention features will be "baked in" in V1 is clear, and I > thought it already had been, though thanks for calling it out here. > > > > Focusing on *only* addressing HTTP in this wire image, though, seems > like it might be dangerous in ways I can't fully articulate yet... HTTP is > an explicitly asymmetric protocol, with different roles for client and > server well beyond the initial handshake, and as it is presently most > commonly deployed, wildly different architectures for client-side and > server-side implementations. Many of the things that we suspect we'll want > to bring on top of QUIC in the future are less so; even Web protocols like > WebSockets fit here. Will this focus lead to invariants that will make less > asymmetric applications harder to build and deploy? Should we be concerned > about that at this point? > > > I do think that peer-to-peer uses of QUIC need attention pre-V1, if > they’re to be supported cleanly. At minimum, we need to arrange the QUIC > headers to easily demultiplex with STUN on the same UDP port, otherwise > we’ll end-up re-inventing STUN within QUIC. Focussing solely on HTTP is > going to make this difficult. > > See draft-aboba-avtcore-quic-multiplexing-00 for more discussion. > > -- > Colin Perkins > https://csperkins.org/ > > > > >
- QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Ian Swett
- Re: QUIC - Our schedule and scope Patrick McManus
- Re: QUIC - Our schedule and scope Salz, Rich
- Re: QUIC - Our schedule and scope Salz, Rich
- Re: QUIC - Our schedule and scope Eric Rescorla
- RE: QUIC - Our schedule and scope Lucas Pardue
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Willy Tarreau
- Re: QUIC - Our schedule and scope Göran Eriksson AP
- Re: QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Mark Nottingham
- Re: QUIC - Our schedule and scope Mark Nottingham
- RE: QUIC - Our schedule and scope Mike Bishop
- Re: QUIC - Our schedule and scope Brian Trammell (IETF)
- RE: QUIC - Our schedule and scope Salvatore Loreto
- RE: QUIC - Our schedule and scope Roni Even
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- Re: QUIC - Our schedule and scope Simon Pietro Romano
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Christian Huitema
- Re: QUIC - Our schedule and scope Colin Perkins
- Re: QUIC - Our schedule and scope Spencer Dawkins at IETF
- RE: QUIC - Our schedule and scope Mike Bishop
- Re: QUIC - Our schedule and scope Philipp S. Tiesel
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Martin Duke
- Re: QUIC - Our schedule and scope Eggert, Lars
- Re: QUIC - Our schedule and scope Olivier Bonaventure
- RE: QUIC - Our schedule and scope Lubashev, Igor
- Re: QUIC - Our schedule and scope Quentin De Coninck
- Re: QUIC - Our schedule and scope Ian Swett
- RE: QUIC - Our schedule and scope Lubashev, Igor
- Re: QUIC - Our schedule and scope Ian Swett
- RE: QUIC - Our schedule and scope Roni Even
- Re: QUIC - Our schedule and scope Bernard Aboba
- Re: QUIC - Our schedule and scope Colin Perkins
- Re: QUIC - Our schedule and scope Joerg Ott