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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Fri, 25 May 2018 08:33 UTC

Return-Path: <mikkelfj@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 DFB251243F6 for <quic@ietfa.amsl.com>; Fri, 25 May 2018 01:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level:
X-Spam-Status: No, score=-1.688 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no 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 2E-6mwEz8vwe for <quic@ietfa.amsl.com>; Fri, 25 May 2018 01:33:45 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 8DAA51201FA for <quic@ietf.org>; Fri, 25 May 2018 01:33:45 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id g14-v6so5516335ioc.7 for <quic@ietf.org>; Fri, 25 May 2018 01:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=MVe37+whc+WlRxd7PydWpbOuHs1MxHv9t0lEMi+RSzQ=; b=ASIOzExAX5kTp00cHwl8Dkycv/ZUOVFXBMK4z7KJs7rKTrAJf3TipSLEzNRbJUqD8a 5fI5QTruO0ibbtz2gTnjhLcTdPTa7y5aw9ghgM0g9tA6fjamTHmCD1pXtKBeYqnDOypT h5CgDgjzYVkqw0mDe5XQg0/bmv4XFtuEmtnl8u1ROSBOryijeCZ6jfwda0UVpnHAvmiQ 1R6vSV8oEoYsgm3SYzlW/KoE75MyC8//SlnrUdXk1RLfh5LF8IGwWBClnsm6EAsz6aIj EbW0Zs5LxtcMrd66nTxr7oFU9D/g1yrXeVQtHHWQvM5BM5UrO9U2dgP0a1BM4IGk8Qql ELhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=MVe37+whc+WlRxd7PydWpbOuHs1MxHv9t0lEMi+RSzQ=; b=GIUijcyVpxOoBSOoR3XV6+sERlj8IqB297JlHXDsUrIxHBPLGXuEoKTMGcTDpBQEHD 7d2OsSPxfkxf6V+LlgWUcGZR/8ZzcVUzvdA2GABaAJCk3T2FKDnH47e6Yf5wmhK+nFsn 1d8GXpSe1gek8kT2sEp2lo2pNfVOKVzNr21eO6VOzEwzf6OKSkgGbSdIGNfFs0aLZqzE ES1jnOIhy13w5baYEeHN19o67+tuatKdZwngCjU45zCiu3byLNGp6DTp8SvBB8+Pn7Ul e8g8wm6/YYCzXbEdzE3T/A0DwiVE8CpuwYK1Mba8pQaC9zFcD6BaP36owHog1AUmuadm fg5Q==
X-Gm-Message-State: ALKqPwdpEo7RSUN4CehkXGhjf+GgsEvStwuJZ+fUUxEpgkzeN1w4Puoi KPbpICWbDgbo6x+RQT6QLeb/kPgliqBsxXDAIzU=
X-Google-Smtp-Source: ADUXVKKObv1J2ZoCo2naeIUmRPtDww5cp3UECqi0cJAokx/rqrhm2guI2Lgm9laoazywQBUzXsJTPeevnR2ffg82yHg=
X-Received: by 2002:a6b:8dc3:: with SMTP id p186-v6mr1128372iod.70.1527237224675; Fri, 25 May 2018 01:33:44 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 25 May 2018 04:33:43 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CANatvzwXhqZBDt59HJCThbdhomGbac=Na0vcofZhPbEYRniV-g@mail.gmail.com>
References: <CANatvzwN1kVO3ofvyYX9cg=cKcg4FdqUT3VB6hneEDa5UjT_0w@mail.gmail.com> <CABkgnnUjw4WYDv5mmsFp2nDq4LtdJBzsgdFkxFzEdHrA37tejw@mail.gmail.com> <CANatvzyNHpTFpdS6_A-gijn2+dOiU=zxyiRJsQuSZVy+EyZ1gQ@mail.gmail.com> <CANatvzwXhqZBDt59HJCThbdhomGbac=Na0vcofZhPbEYRniV-g@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 25 May 2018 04:33:43 -0400
Message-ID: <CAN1APddOMnmf_dAEpVZEjuL2xx5GYK08MHrHBO_OY9JUh+jtjQ@mail.gmail.com>
Subject: Re: Stream0 Proposal: Explicit vs. Implicit ACK (Re: Stream0 Design Team Proposal)
To: Martin Thomson <martin.thomson@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Cc: Eric Rescorla <ekr@mozilla.com>, Jana Iyengar <jri.ietf@gmail.com>, QUIC WG <quic@ietf.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000043bf65056d03a0af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JUrvtRF6P-4NGKlGHC4h0KEFRz8>
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: Fri, 25 May 2018 08:33:48 -0000

The overview doc seems to be clear on ACK’s in general, not sure about EOED
specficially.

https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit

section 2.2

ACKs in 1-RTT packets will acknowledge the receipt of 0-RTT or 1-RTT
packets.  ACKs cannot be sent in 0-RTT packets.



Kind Regards,
Mikkel Fahnøe Jørgensen


On 25 May 2018 at 10.06.49, Kazuho Oku (kazuhooku@gmail.com) wrote:

I think I might have found an issue in the explicit ACK approach that
we use in the PR.

That is that EOED cannot be ACKed.

Assuming that EOED is sent using 0-RTT keys, it needs to be acked by
the server using the same key, because the transmission of EOED needs
to be guaranteed for the TLS handshake to complete.

However, there is no 0-RTT send key on the server-side.

Do we have any rule for dealing with this? I searched though the text
of the PR but could not find an answer.


2018-05-24 14:49 GMT+09:00 Kazuho Oku <kazuhooku@gmail.com>:
> 2018-05-24 13:43 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
>> 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 <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
>
>
>
> --
> Kazuho Oku



-- 
Kazuho Oku