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

[Kazuho Oku <[e-mail]>]

2018-05-24 13:43 GMT+09:00 Martin Thomson <[e-mail]>:
> The obvious solution for the problem of not retransmitting the client
> Finished is to retransmit it until it is acknowledged.  With the proposed
> design, that means that the server sends a Handshake message after the
> handshake is done, which I think is fine.  If the client sends Finished
> until it is acknowledged, then I think we're good.

I agree that that would work.

IIUC downsides compared to the implicit ACK approach are that the
server needs to keep the old keys for certain amount of time (e.g., 2
MSL) and that the additional Handshake packet will consume about 30
octets of the 3 packet window that we have for the server's first
flights.

> I can see the appeal in saying that if you receive an ACK for 1-RTT data
> then your Handshake packets must have been received.  I can see that
> working even, but you have to be careful.  It's just a signal that you can
> stop sending CRYPTO frames, not that you are done with the keys.  You might
> need to send ACK again and you might still receive packets at that level.
> You could drop read keys and ACK only the old packets that you did decrypt,
> but I suspect that it's better to authenticate any packet and ACK
> faithfully, which would be better for your peer's congestion state.
>
> That also means that you probably need to have timers for cleaning up, to
> avoid the pathological case where acknowledgments are sent indefinitely.

I agree with your argument about congestion control.

One way of acquiring correct congestion control information in the
implicit ACK approach will be to send coalesced packets that combines
a Handshake packet with a packet protected by a higher encryption key.
That will guarantee that you would receive an ACK for the delivery of
the datagrams, and you can feed the information to the congestion
controller.

FWIW, I have implemented implicit ACK in quicly, and it only required
about 40 additional lines of code, including the retransmission logic
for Handshake_Done. The code can be found at
https://github.com/h2o/quicly/pull/8/commits/eee6eb5fc7c0359edfeb0b8f89ae9ac191ef0758.
Coalesced packets is not implemented.

>
> I think that the FIN bit idea might work to close out the use of the
> "stream" for each set of keys. That is, as opposed to the crypto stream as
> a whole.  But it's duplicative: the crypto handshake needs to know when it
> moves from one set of keys to the next and replicating that signaling at
> the QUIC layer only really adds things to check for consistency.
> On Thu, May 24, 2018 at 11:07 AM Kazuho Oku <[e-mail]> wrote:
>
>> 2018-05-24 3:46 GMT+09:00 Jana Iyengar <[e-mail]>:
>
>> > 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
>> impossible.
>
>> 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



-- 
Kazuho Oku