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

Martin Thomson <martin.thomson@gmail.com> Thu, 24 May 2018 04:44 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5911204DA for <quic@ietfa.amsl.com>; Wed, 23 May 2018 21:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00Ydr-EAW7M6 for <quic@ietfa.amsl.com>; Wed, 23 May 2018 21:44:00 -0700 (PDT)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745211200A0 for <quic@ietf.org>; Wed, 23 May 2018 21:44:00 -0700 (PDT)
Received: by mail-ot0-x22f.google.com with SMTP id t1-v6so372973oth.8 for <quic@ietf.org>; Wed, 23 May 2018 21:44:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Re32adJoIhdI6DVhDYzV/VlGJgPRHOBLsMZKRW1PK1M=; b=sSmHC3W1gqUBMjKglSyKIAQrSTE26OLLnNm3+9i2gjdIe8jLD4DsUCPaAjTCX7uw1b BXxc1pV6ABgVUeokfsIo60z3yzAwN9GOUSldmXtmPo79b/UJ/zc9xO2gPrQsNYF/Y3cG i3JwIxcJuTsEJCHlik06+p/NNoKw00WT/Rnw5oQJg+oweHqFDBvsP3jjHikPAZ9+Z9vV mkCszNtLAhhbIFnQY/Ay2FsA7dDuTt7hj6Cnifi9bJegmo+SE/IiiXOotMWHkJ93zZ7n Xs/J77fpMdTPuPDmAMX1TcAjtGHzrStNbPkDG0FTGBbpQN6IQd2Z2LbdatNfbuV9EiKI kq7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Re32adJoIhdI6DVhDYzV/VlGJgPRHOBLsMZKRW1PK1M=; b=qNi7Zf0KHg5DbhMDbwWbGO8nW6I664nb++rkc/1OM/MisynKimms9MhaTZ4d5etMgk hVY2UqQPvDf23DJjR4OHrmi1cZF4ljy6+TnVyxIMWU+UicYROktdMZJbXku924mnZGb7 e9wLvj7m8DQIxZec6bEQcmi4eoI9DjiC9XreHzG4yjTLS2LipEOaTdC4HM9Ye5Lgir3y oNzWoTp1EKXYOAgGeJNzqIU2fl6s2vZUT9IMIkiAivkKYV4SrEk9GF2nGrIyJiNf89Cy jfXR4FuyjP6H5gKH2S/tTXV3QO6yKJ/g2WHlyO4J3YPuJAoxO5RG6c47bv49vlO0LHuF x38Q==
X-Gm-Message-State: ALKqPwfypCC0NTBselAKC2e73lmmbmo1TJA0r+pnz12o58sTaJWzmqrK hx2hF8zr8KEArMPBLUcC+n0QlWV+mrQSF0HPXNg=
X-Google-Smtp-Source: AB8JxZpmG4OuErp2S37rN3jY/9b7SZlj0grskowXwKbsOqRWeoikWEnDgDK+A9HJkT0UqvPBfWQqr4klCHJlPxAVx+Q=
X-Received: by 2002:a9d:3ea5:: with SMTP id b34-v6mr3371574otc.283.1527137039627; Wed, 23 May 2018 21:43:59 -0700 (PDT)
MIME-Version: 1.0
References: <CANatvzwN1kVO3ofvyYX9cg=cKcg4FdqUT3VB6hneEDa5UjT_0w@mail.gmail.com>
In-Reply-To: <CANatvzwN1kVO3ofvyYX9cg=cKcg4FdqUT3VB6hneEDa5UjT_0w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 24 May 2018 14:43:49 +1000
Message-ID: <CABkgnnUjw4WYDv5mmsFp2nDq4LtdJBzsgdFkxFzEdHrA37tejw@mail.gmail.com>
Subject: Re: Stream0 Proposal: Explicit vs. Implicit ACK (Re: Stream0 Design Team Proposal)
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>, ekr@mozilla.com, QUIC WG <quic@ietf.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kdyE2nGc4EpYXNw3CZUulNvhlfg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 04:44:03 -0000

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 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 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 <kazuhooku@gmail.com> wrote:

> 2018-05-24 3:46 GMT+09:00 Jana Iyengar <jri.ietf@gmail.com>:

> > 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