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

[Kazuho Oku <[e-mail]>]

2018-05-24 11:07 GMT+09:00 Christian Huitema <[e-mail]>:
> On 5/23/2018 5:41 PM, Martin Thomson wrote:
>
>> On Thu, May 24, 2018 at 10:06 AM Kazuho Oku <[e-mail]> 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) {
    set_len_bit()
    varint_encode(len)
    emit_payload()
} else if (payload_len <= window) {
    if (payload_len != window)
        prepend_padding_before_the_frame()
    clear_len_bit()
    emit_payload()
} else {
    partial_write...
}

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