IETF Logo Mail Archive

Re: [quicwg/base-drafts] Flow control for post-handshake CRYPTO messages (#1834)

Kazuho Oku <notifications@github.com> Fri, 05 October 2018 02:15 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 0D1F5130DC7 for <quic-issues@ietfa.amsl.com>; Thu, 4 Oct 2018 19:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.455
X-Spam-Level:
X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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, URIBL_BLOCKED=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 Wy5mZCrAVRgy for <quic-issues@ietfa.amsl.com>; Thu, 4 Oct 2018 19:15:08 -0700 (PDT)
Received: from out-10.smtp.github.com (out-10.smtp.github.com [192.30.254.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C27A12F295 for <quic-issues@ietf.org>; Thu, 4 Oct 2018 19:15:08 -0700 (PDT)
Date: Thu, 04 Oct 2018 19:14:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538705708; bh=drAwJPYTpugJY5dTsFBBmKMP4tHyllFcEyCokgb3hxk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qayxv7OPXPLrePoWHQPq3phNGKkNE8QkvPbf9A6GibB7fNei8d4U1Y/PDh0uG4GVh Rrr+BCXuHRnwQF2AIqyzgrQZLU8JM+VIi5U6NKXLXbV+hMwWXNQ3NORCGUeu3dg6Gx nsQIQoIYl9BG2Uf5ytHZ2c2QgqBZSGZRfViasB2g=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abf0c750492162f0539e5fe118f259a0c9c0fd909f92cf0000000117ce8b2192a169ce15e0229d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1834/427225638@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1834@github.com>
References: <quicwg/base-drafts/issues/1834@github.com>
Subject: Re: [quicwg/base-drafts] Flow control for post-handshake CRYPTO messages (#1834)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb6c9212ae28_5a393fd7450d45c49221"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/IwCuD28ZzJm4NHRfN3tn0_9MNqk>
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: Fri, 05 Oct 2018 02:15:10 -0000

> The client can now send a bunch of post-handshake messages to the server which the server cannot process until it receives ClientFinished, so it has to buffer them. We should bound that buffer somehow.

Isn't the expected behavior of the server to drop the 1-RTT packets containing the post-handshake messages until it receives the ClientFinished (that activates the 1-RTT read key)?

To put it another way, my understanding is that you _can_ have any size of buffer you want to better cope with packet reordering, but that happens per-packet rather than per-frame (because it's not just the post-handshake messages that cannot be trusted prior to receiving ClientFinished), and that the buffer can be arbitrary sized because you can drop it to trigger a retransmit.

Am I missing something?

-- 
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/issues/1834#issuecomment-427225638

v2.23.0 | Report a Bug | By Email