RE: QUIC - Our schedule and scope

Roni Even <roni.even@huawei.com> Wed, 01 November 2017 06:45 UTC

Return-Path: <roni.even@huawei.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 E60E313FDCB for <quic@ietfa.amsl.com>; Tue, 31 Oct 2017 23:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 rskvH-ua5Fj8 for <quic@ietfa.amsl.com>; Tue, 31 Oct 2017 23:45:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA08213F618 for <quic@ietf.org>; Tue, 31 Oct 2017 23:45:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZB19636; Wed, 01 Nov 2017 06:45:02 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 06:45:01 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Wed, 1 Nov 2017 14:42:32 +0800
From: Roni Even <roni.even@huawei.com>
To: Colin Perkins <csp@csperkins.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>
CC: Mark Nottingham <mnot@mnot.net>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@netapp.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: RE: QUIC - Our schedule and scope
Thread-Topic: QUIC - Our schedule and scope
Thread-Index: AQHTUOD5OYwD1bY2Q025S94sx4OA0aL/FxEw
Date: Wed, 01 Nov 2017 06:42:32 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD82A677@DGGEMM506-MBS.china.huawei.com>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <AE0180A5-7577-44C0-8FF6-0AFD1E3B9E00@trammell.ch> <EF177987-B730-4FDB-898D-8036F6B95B28@csperkins.org>
In-Reply-To: <EF177987-B730-4FDB-898D-8036F6B95B28@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.65]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59F96D6F.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7c2ad93f9370a4c512b2ebd712b97e60
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ywODhSyGPTpiG9FHzn9xSy75Wp4>
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 06:45:08 -0000

Agree with Colin and this is one reason for my concern about the "invariant" in V1 based only on the HTTP use case.
Roni

> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: יום א 29 אוקטובר 2017 20:08
> To: Brian Trammell (IETF)
> Cc: Mark Nottingham; QUIC WG; Lars Eggert; Spencer Dawkins at IETF
> Subject: Re: QUIC - Our schedule and scope
> 
> 
> > 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/
> 
> 
>