Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)

Nick Harper <notifications@github.com> Tue, 19 March 2019 06:08 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2769130F1F for <quic-issues@ietfa.amsl.com>; Mon, 18 Mar 2019 23:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 NV5mW_uybInn for <quic-issues@ietfa.amsl.com>; Mon, 18 Mar 2019 23:08:45 -0700 (PDT)
Received: from out-12.smtp.github.com (out-12.smtp.github.com [192.30.254.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B511277CE for <quic-issues@ietf.org>; Mon, 18 Mar 2019 23:08:45 -0700 (PDT)
Date: Mon, 18 Mar 2019 23:08:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1552975724; bh=k9L1FHHAGSM8BF2sHPn1gHF/4D7l5c3nG5Vtwimbyfg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Esx/k1Pd7SkjCOtTsvJglNDCZHiuVEmOLr0n1CKdTUc6MihH6ZmQt47Z+hVG0j4kF UpT8dDDIFwzNSRKjwSvHCgBCdVVZ8uCcCLKRUj0R5xNzHTxf3Nx4r7pjZ12LHIRdmz dNCLr8d28jEE75LOzsYO5n87pfMhhkfmjAYHBlJY=
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab64a0a9cadac8e962692866aff0b1e0e8d02ebcb092cf0000000118a8496c92a169ce192348df@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2524/c474210701@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2524@github.com>
References: <quicwg/base-drafts/pull/2524@github.com>
Subject: Re: [quicwg/base-drafts] Specify behavior for post-handshake CRYPTO messages (#2524)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c90876c3ca36_2fb63ff5434d45b8149527"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/01ASYKBCOBfA1Gb1QXWNgQ2H1QQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 06:08:47 -0000

We discussed this in Tokyo ([minutes](https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.md#flow-control-for-post-handshake-crypto-messages-1834)), and there are basically 3 options here:

- Implement proper flow control for CRYPTO frames
- Specify a buffer size (50k is the example from the Tokyo discussion)
- Drop CRYPTO frames if an endpoint has to buffer too many

My sense of the room was that the 3rd option was the preferred option for now.

When we have TLS extensions where we care about reliable delivery of post-handshake messages, that sounds like a good time to add proper flow control. I don't like picking a fixed buffer size for the same reason as using timers for discarding keys. If we pick a buffer size now, how do we know that it will be big enough for whatever future TLS extensions might get used with QUIC (or future key exchanges)?

I don't think that this breaks a rule of acknowledging packets means that the peer has processed all frames in that packet. For example, if an endpoint receives a packet containing stream data that is a retransmission of previously received data, that endpoint in effect is dropping that STREAM frame. Here, the CRYPTO frame is being processed (and the endpoint is immediately choosing to do nothing based on it).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2524#issuecomment-474210701