Re: Stream0 Proposal: CRYPTO_HS frame encoding (Re: Stream0 Design Team Proposal)

Kazuho Oku <> Thu, 24 May 2018 05:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB51B1205F0 for <>; Wed, 23 May 2018 22:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nO4FYxdCjl7m for <>; Wed, 23 May 2018 22:54:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3821012D948 for <>; Wed, 23 May 2018 22:54:09 -0700 (PDT)
Received: by with SMTP id v24-v6so364489plo.3 for <>; Wed, 23 May 2018 22:54:09 -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=+iD7jYdef3Q4MSgXQ6lokgU+cbR3Etfzwlxcpe4j4r0=; b=lRC4S+77C4NiY+n+iCUzEBoDnudVCwJpxAoQ41xb7jd9GcJY5ukdfkhzOcVAqAdrn+ nrbKqFXfCDhzwyr/o/yFBpGag06NULDKE8PGez8i+bA9UJwPs31NWi7bA2UXKj9Gp3aH rCwFeT/syMH9i8SNLRkdtXX83GDLfgtpUjd0CA57DMUQxzxgQJEHF7DkMAGfrU7JmY1o WRF7un4qlY7lTsE7v2XEuTjj6VBmX4/cFcMhIxdyVglX5KLJT4EXqY8nqMwlx3vz7agt SP+bZjf3qmrbV7dKMZ9bPIXnKXEBmm7gRR4NQF8F2Wm/pdc+V9UNdXN0Elq8uqxv7qIS 0N8w==
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=+iD7jYdef3Q4MSgXQ6lokgU+cbR3Etfzwlxcpe4j4r0=; b=X727aEOhkCU+cM7GqMvQC01iN2GOpZqUkSgzi/C3cwNM9uz6AgaeiRZHXRzzVYws9D Pbr6uR+bh0b1yPKXYQ468OukJzZ1oyX0F+HNxTkZA9BfEYt6Sf9px3REhlXm5MwU0ox4 Ix7SsD3Ui5Ud8zh0sQthhTR0z4RTlxeDR/EUqG99dSSfX1HEjGjDe8WPjdmHEQwomkw7 6exi+3At+nFxofcZzhRJkqVx3EkdR0IPR5ZxI3iJP+QnG4qEsYyRzJckSKvglggV7jqW 5j0a+VvDi8j98dS8+ZL+vVDQTJGZF3fQ95hmFeB2vYCKCgAZJvemF6wPT16DFC/inxuC 8yCA==
X-Gm-Message-State: ALKqPwfJi+nU2yhxiRgbpQRAciLosyG5XHu+NF0TJZDOfRll+0M9WK02 M0n8Y8CmpyAyDfJjiP0IV1iEBYGz7qX++fOw5eAkYw==
X-Google-Smtp-Source: AB8JxZpWE5t0I9s4jHUPVnhLC0MVK1i0dVN/LyYd/JJgJgnlx1oQCwKlL9qjRcH+FXj02zb2EEOA3E3CMl9SBRqkDw0=
X-Received: by 2002:a17:902:ba87:: with SMTP id k7-v6mr5914006pls.193.1527141248800; Wed, 23 May 2018 22:54:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1189:0:0:0:0 with HTTP; Wed, 23 May 2018 22:54:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Kazuho Oku <>
Date: Thu, 24 May 2018 14:54:08 +0900
Message-ID: <>
Subject: Re: Stream0 Proposal: CRYPTO_HS frame encoding (Re: Stream0 Design Team Proposal)
To: Christian Huitema <>
Cc: Martin Thomson <>, Jana Iyengar <>, Eric Rescorla <>, QUIC WG <>, Ian Swett <>
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 05:54:12 -0000

2018-05-24 11:07 GMT+09:00 Christian Huitema <>:
> On 5/23/2018 5:41 PM, Martin Thomson wrote:
>> On Thu, May 24, 2018 at 10:06 AM Kazuho Oku <> wrote:
>>> 0x10 - 0x17: STREAM frame
>>> 0x18: CRYPTO_HS frame
>> ....
>>> I think that is workable, although it makes me sad because we will
>>> have more conditional branches.
>> Yeah.  We have an extremely limited space here.  And while Jana is right
>> that we haven't used much yet, we're only just starting.  As for
>> conditionals.  Maybe.  One way to implement this is a switch statement, and
>> those might not suffer as badly when you consider that you also have to
>> dispatch to other frame handlers in the same piece of code.
> I am with Martin on this one. Just one code point for crypto frames,
> please. At best the optimization saves 2 bytes in the entire duration of
> the connection -- one byte for the CH, one byte for the first frame of
> the SH. And for the CH, you don't care because you are going to pas to
> min length anyhow.

FWIW, I disagree with the calculation.

My understanding is that having the OFF bit saves us 3 octets on the
server's flights and 2 to 3 octets on the client's flights per each
connection, because there will be 3 to 4 encryption levels and because
CRYPTO_HS will appear in all encryption levels except the client's
1-RTT flights.

The LEN bit has a bigger impact. It saves 4+2N octets where N is the
total number of Initial and Handshake packets sent by the server,
assuming that SH and NST will be larger than 63 octets.

So we will be using additional 13 octets in the first 3 packets that
the server sends.

OTOH, I do agree that additional 13 octets is big enough to justify
consuming more code points by itself. It's somewhere around 0.3% of
the amount of data you can send in 3 packets.

> You can still do common code with the "stream" data even without that,
> you just need two small branches of code to parse the stream id, stream
> offset, and stream fin. Just default to "stream=Crypto, stream offset=
> always present, stream fin= false" in the crypto branch.

The thing that makes me sad is the omission the FIN bit making the
encoding side complex.

With the FIN bit, we have the guarantee that a payload of any size can
be sent without additional overhead. That simplifies the encoder
logic. What you do is:

if (payload_len <= window - 2) {
} else if (payload_len <= window) {
    if (payload_len != window)
} else {

Without the FIN bit, the framing code becomes completely different
because we will always have the overhead of the length field, and the
length of the length field depends on the amount of payload or the
space we have.

> -- Christian Huitema

Kazuho Oku