Re: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC

Kazuho Oku <> Thu, 24 May 2018 00:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C723712751F for <>; Wed, 23 May 2018 17:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MmaTwZhzmerq for <>; Wed, 23 May 2018 17:42:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22D2F127201 for <>; Wed, 23 May 2018 17:42:42 -0700 (PDT)
Received: by with SMTP id q22-v6so11312982pff.11 for <>; Wed, 23 May 2018 17:42:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n9sagG6fKSJP+8k9ZEHBc/76V67/ipUKO8JyIxtxYRE=; b=XjhfSVUN6Xb2/WwGud/RYrLSWvReHoMtcUCz0vlWCdI+ta5vVsQtvQC9c2dh2DbvEt UuOI9Ad4VZ1tgRJp1DEYoxAGmSyYFY5WuvEVBO4JTCoJDmdmDXqjZ4vDjM13vRnsCotk 2Jc7BWQMDoQWQsUX0EABH5jonCIgO3gQz/p8NcpooGZfG6bQbAeMqGjD6uGfseR3mtag ET/6eyfwGfJt6UjS1ecvZoRO3luErZ9/ALQNaGQGuaXDfqANK/HhovqA4Lxfyhy84lU+ 7vM98YdeBIsgP8BruC8w+aN4E4/zDTx377UsGEco9D4pZ+KOM6VV92ALyWLjRIDP6ILT x36A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n9sagG6fKSJP+8k9ZEHBc/76V67/ipUKO8JyIxtxYRE=; b=AJcB3Tqs3j0zUVKU26bSddS0ymiU8yj0zzgI1qsdfVV7Ovi+abKHm+xoOE1en3y6zk B8fd4gX16epPPUpWC8TbflRahCYUljzrsAGF3SxNRBwK+aSOwicI/WkZpqhfh0guento MEzx5SqPSA33bsUrTUtyOrGBo/HMKrKEdZMu9oge5mOB0H+Dg+G/5pBYoQXXlhn+IFcs XMdGAxzb4ON4B4SLRUbmBwCwg1VqB/Xs9B5SOiy/VdWjKkXg1Q5JvAUUF7ngvC5l/1RB SZrGPz5HYUgavN1nxl768Lua8Mzzj6sRPSyLbZxTpgxiww//UnyU1pLzG422tgib+bTH JpuA==
X-Gm-Message-State: ALKqPwcy6Nkrt27Oqh3Iq6VrCVBTJ7vtTCvznp7908hLkU2kyS4LvjFu aNJnAsWTXQwRt/X1EmfmNCoqyGcIuMbPuUZK+tA=
X-Google-Smtp-Source: AB8JxZpTyE+JG1VtsaEAgpfrSG5URvsRJGj49ECLNiHmY3UdFOMX/+ZkGd5Mhr/Z4ymCfe8ZUaU4owZLoTS9ME1sq7s=
X-Received: by 2002:a63:7c04:: with SMTP id x4-v6mr3939420pgc.67.1527122561547; Wed, 23 May 2018 17:42:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1189:0:0:0:0 with HTTP; Wed, 23 May 2018 17:42:40 -0700 (PDT)
In-Reply-To: <>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB3F654@bgb01xud1012> <>
From: Kazuho Oku <>
Date: Thu, 24 May 2018 09:42:40 +0900
Message-ID: <>
Subject: Re: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC
To: Jana Iyengar <>
Cc: Lucas Pardue <>, Ted Hardie <>, IETF QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2018 00:42:44 -0000

2018-05-24 9:05 GMT+09:00 Jana Iyengar <>:
> I agree that we must grapple with the question of what this proposal does to
> the timeline and that schedule needs to be a part of the discussion.
> That said, I think this needs to be done in context. Going into London, the
> editors spent three days whittling down and addressing open issues as best
> we could. This was presented during the wg meeting. Importantly, the list of
> issues that we had no clear ideas or direction on how to fix were all around
> the handshake (see slide 9 in this deck.)
> The set of handshake issues is probably the most difficult and glaring one
> at this point in the list of pending QUICv1 issues.
> Solving them with the DT's proposal moves us closer to our goals. Yes, it
> will take time, but how much time any other solution(s) take? We have only
> one other real proposal that fully solves all those issues: some form of the
> QUIC/DTLS proposal. The DT spent time with further generations of
> integrating QUIC and DTLS, but among others, there are concerns of available
> implementations and implementation maturity there. Additionally, that
> proposal ends up tying up QUIC and DTLS standardization processes in ways
> that may cause even more delay and limit future evolution. It may be worth
> documenting the alternative DTLS proposal and why the DT chose the proposal
> it did, for posterity.

FWIW, I have added Appendix C to the design doc that briefly explains
the DTLS-based approach as well as the reasons why we abandoned it.

The text is rough and is likely to have some aspects missing, I would
appreciate it if anybody in the Design Team could improve it.

Lastly, the comparison of the wire formats between the DTLS-based
approach and the proposed approach might give us a clue on what the
difference of security aspects are between DTLS and the proposed
approach. I think that it is more natural to compare the proposed
approach to DTLS than to TLS when discussing about security aspects.

> I agree that we should have a discussion on what this proposal does to our
> timeline. But I'll note that this is finally a timeline that would include
> real solutions to important open issues that need solving for QUICv1 to
> finish.
> On Wed, May 23, 2018 at 2:47 PM, Lucas Pardue <>
> wrote:
>> Hi Ted,
>> Thanks for your thoughts.
>> > My back of the envelope calculation is that this means at least one more
>> > cycle of specification and interop will be required before we get back to
>> > where we are with draft -11, and that estimate is because I'm in a hopeful
>> > mood that Sean and Eric can move the required work in TLS along.  A more
>> > practical Ted would see this as adding at minimum 6 months to the schedule.
>> > The changes in TLS are also large enough that I expect that the deployment
>> > time to see significant penetration of the new libraries to be longer than
>> > it would be for the previous design.   Call it 9 months, with 3 months of
>> > error bar.
>> I can't talk to the merit of this proposal in relation to QUIC transport.
>> As somebody greatly interested in application mapping (with a WIP HTTP/QUIC
>> implementation) I have concerns that progress in this area keeps being
>> pushed back. We have little interop experience in this area to feed back to
>> transport.
>> A particular sore point is that the handshake-oriented changes have weak
>> relation to QUIC "steady state', upon which application mappings depend.
>> E.g. Draft 09 and 12 differ little in handling of STREAM frames.
>> Regards
>> Lucas

Kazuho Oku