Stream0 Proposal: Explicit vs. Implicit ACK (Re: Stream0 Design Team Proposal)

Kazuho Oku <> Thu, 24 May 2018 01:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F652127077 for <>; Wed, 23 May 2018 18:07:36 -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 9oZsc-HhAUdG for <>; Wed, 23 May 2018 18:07:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87855124217 for <>; Wed, 23 May 2018 18:07:34 -0700 (PDT)
Received: by with SMTP id w3-v6so10161644pgv.12 for <>; Wed, 23 May 2018 18:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=gXO1t5yUchixC9j7AfiC8oViCJdc7MG2auqsQfEw0/8=; b=l7aRKkEaLPyWqTYKPGnc8ihQg7Hrehc3x+wClybb6Op8kHPF37rwOHfGIVHinzlJwt 3a+AZtpcVo51MHqZfY1TR/Iz9QXkIvJM43TXcDVY7XpTz5pI7Pj/2Fb2y+K59X8k5TNy LHN6iUH1gFWFfUVBDNBRbzSB2SVVp/T/Sj/SGOlOJ3uh4ZTQY+WJU7iILKm++Fye2a8J 29hg7I+AIcghwQAnLmArgV4upe/2XA/E9EltDmlMgCifrTDeUyxYqqm92lsGVdU6195V k8jBz/LIttpfv/cnn3VQlG3Wb7bXxptwKvDGG6n5bxBVdh6f1trJMxOy/tPbFqbYAlKo hhvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=gXO1t5yUchixC9j7AfiC8oViCJdc7MG2auqsQfEw0/8=; b=Be7uJz/D6/RHKX4mDAUSRCgfr2m5KHts/4XVK9vUDBmA+/HJUvCu+wZd+gKZ9Q7cUW 8P+H/7MTqRQnSPpLSry8bx3VMYi8nSulWyjR5nD3R4QarZaHqVOshPElEkcTaFx/gMUi Y2V6rZIu7EHCfe/pmIP/HGMacP6tgNK0SiS+tz/w+o6BhmGHikOwoZz9AgeZGF2TZEQG +PKExDbmXuQ2qHyLDpO8KiEMPzry/UNxns+5/tKdZyjlORmXlUfKmstAh0jufr8O2p5M Li1C49n6LwsYj8subJUnTmsJmzpKRv/rXFCVLnrXZbf4d1vdHtKxBN/l0S93GAAzjj5T BHrQ==
X-Gm-Message-State: ALKqPwcvPw5nH91GEd5EuqOATx9GNGHBk6kmPQFJN1MLja+iCcU1m9O2 B1UzRSpEcVC8vabaVoQzImFf/X46sSFI1g8CBmA=
X-Google-Smtp-Source: AB8JxZoojEuik0L2olqbAveGV5wFEBY13zJYTDGGKQl3yOSxPElWAFN5IS+E+7jQVkTcQCw/l54uPmh6M1dT4W2sLeA=
X-Received: by 2002:a65:61c8:: with SMTP id j8-v6mr4029748pgv.370.1527124053990; Wed, 23 May 2018 18:07:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1189:0:0:0:0 with HTTP; Wed, 23 May 2018 18:07:33 -0700 (PDT)
From: Kazuho Oku <>
Date: Thu, 24 May 2018 10:07:33 +0900
Message-ID: <>
Subject: Stream0 Proposal: Explicit vs. Implicit ACK (Re: Stream0 Design Team Proposal)
To: Jana Iyengar <>
Cc: Ian Swett <>, Eric Rescorla <>, 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 01:07:37 -0000

2018-05-24 3:46 GMT+09:00 Jana Iyengar <>:

> A thought occurs to me: a CRYPTO_HS frame with the fin bit set can be used
> to indicate that the handshake is done.This could be used as a signal (aka
> HANDSHAKE_DONE) to solve Marten's problem of a client rtxing a CFIN. Of
> course, this would mean that this particular CRYPTO_HS frame would be
> encrypted with a 1-RTT key... which *I think* is fine. What do you think?

I am not sure if that is a good approach.

I would assume that we would like to keep the handshake flow on the
1-RTT key open for the lifetime of the QUIC connection, so that we
could send things related to the TLS (e.g. session tickets). Sending
FIN from the server right after receiving ClientFinished makes that

Having said that, I do agree that the need for a dedicated frame is a
pain. It is a pain because we need to have a retransmission logic for
the frame.

I think that you are making a good point in suggesting to consider
reusing the retransmission logic that already exists for bidirectional
flows. But as said, FIN bit does not seem like an answer in this case.

IMO, ideally we should define a new TLS post-handshake message (that
does not convey any data), and send that from the server in response
to ClientFinished using 1-RTT packet. The message will act as a signal
that the server has received ClientFinished.

The benefit of this approach is that we can reuse the retransmission
logic that will exist for handshake flows. The downside is that TLS
stacks need to be aware of the new handshake message.

Considering the fact that the Design Team is already suggesting a
substantial change to the TLS stack, we might have chance in asking
for the addition of a new handshake message. But I am not sure.

Kazuho Oku