IETF Logo Mail Archive

RE: QUIC - Our schedule and scope

Roni Even <roni.even@huawei.com> Sun, 29 October 2017 06:36 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 34F84139435 for <quic@ietfa.amsl.com>; Sat, 28 Oct 2017 23:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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] 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 5PrX_ftAFPyv for <quic@ietfa.amsl.com>; Sat, 28 Oct 2017 23:36:32 -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 54D701389E1 for <quic@ietf.org>; Sat, 28 Oct 2017 23:36:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYV31418; Sun, 29 Oct 2017 06:36:28 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 29 Oct 2017 06:36:27 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Sun, 29 Oct 2017 14:36:24 +0800
From: Roni Even <roni.even@huawei.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Mark Nottingham <mnot@mnot.net>
CC: 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: AQHTTuyjzH0XqhPpaUudBuwTgSLIsqL4YtaAgAH/mLA=
Date: Sun, 29 Oct 2017 06:36:23 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD828A2F@DGGEMM506-MBS.china.huawei.com>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <AE0180A5-7577-44C0-8FF6-0AFD1E3B9E00@trammell.ch>
In-Reply-To: <AE0180A5-7577-44C0-8FF6-0AFD1E3B9E00@trammell.ch>
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="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59F576EC.003C, 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/0OF3QNNHbgMK2KjJ0nHktb_e2-o>
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: Sun, 29 Oct 2017 06:36:33 -0000

Hi,
Sorry for raising the same issue again, I only noticed this email after I sent my feedback
Roni

> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
> (IETF)
> Sent: שבת 28 אוקטובר 2017 11:05
> To: Mark Nottingham
> Cc: QUIC WG; Lars Eggert; Spencer Dawkins at IETF
> Subject: Re: QUIC - Our schedule and scope
> 
> 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?
> 
> Thanks, cheers,
> 
> Brian

v2.23.0 | Report a Bug | By Email