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

Jana Iyengar <> Thu, 24 May 2018 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DE561273B1 for <>; Wed, 23 May 2018 17:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 XQJjmCtGt--I for <>; Wed, 23 May 2018 17:05:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4956F124217 for <>; Wed, 23 May 2018 17:05:58 -0700 (PDT)
Received: by with SMTP id c3-v6so176317itj.4 for <>; Wed, 23 May 2018 17:05:58 -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=BefT/fXTLn/aXNL1+Dk2tXVOlmRGV0NkCsVc58MgnI0=; b=iHlB8jKAo9MQPlYlw+JPgnbUEO/xgwYHe0Y/pqkqfcUYq5DB8CqvmavbOPFgI0Vlr9 5lytcTL3t7bd268dYK84Jaso1u9Qv3L+5VFTEVDqFHc+ZWw7nlJZ8DWbnBxA4Q3VtDU3 yz2g26LALrwu9XQtBlBNqtrv8mnNoGeGz4+yowh5+NN5Jn8w8kDiW9S76VRzatzSZL6x unKh0AP6SVH2/4QrcA0hdV+72JFeWa6qdNQxsuOh2hHakWggRgj6NvCj6nFh+II1UtsS JWytB2e+jk++q5wzLd+pR+ii2K+v6MdbSw2TytKkITzTZctN1Z/7TQw7pz5CE2vhg/Tk 0W7Q==
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=BefT/fXTLn/aXNL1+Dk2tXVOlmRGV0NkCsVc58MgnI0=; b=aO2giQ0Jgk8/NLgZ73JKudZkqphelVHnlr0Fu82E4AwDpmcX2WN0EQKVSLfwsUTcRV o9OUnzFJxSw3EMXsM2Xq0g5pEpoiMmFhsfmx+PfCw3lO3YDGt7QkNVWn5S/jH+8OEXtr h2W+W4DXZp10Yau4O4sonUJSZ23hQgiqSQTGP34iT1xDj+wxrxB7rTEYGxDTkOT7SbWS 7zYuljev+bOqoEkRjXwPPBB6q4p3/6RTJqSeHh44x6Keyd8rtsHs4mda/avH2gi0HOJB q1lAybSvahDPxc6VBuDQaUvPwL+IwuujxmvhY+rFF3/kUcazLs61qCKUDGxuzvCRvlYG 2nlg==
X-Gm-Message-State: ALKqPwdJV8xM6HMnDZKeqhDsa7yWRZpLaY61Tu86atb3uWkrZtprGivM Aab/kCAkjon/Q6ncV6g0c8ZBZtAke22R2kM8faA=
X-Google-Smtp-Source: AB8JxZoPqFGYQV9/+wL5n0Ge9S9si194pLLRpYp8MiL422Ak4q5Q55akwq7qVq+YdVATNtdJxQnzHUmub+S4KbG31fQ=
X-Received: by 2002:a24:36ca:: with SMTP id l193-v6mr7106835itl.103.1527120357489; Wed, 23 May 2018 17:05:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:27d4:0:0:0:0:0 with HTTP; Wed, 23 May 2018 17:05:56 -0700 (PDT)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB3F654@bgb01xud1012>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB3F654@bgb01xud1012>
From: Jana Iyengar <>
Date: Wed, 23 May 2018 17:05:56 -0700
Message-ID: <>
Subject: Re: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC
To: Lucas Pardue <>
Cc: Ted Hardie <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000007003e5056ce86aef"
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:06:00 -0000

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.

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

On Wed, May 23, 2018 at 2:47 PM, Lucas Pardue <>

> 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