Re: [quicwg/base-drafts] Server might be unable to complete handshake due to MAX_STREAM_DATA (#725)

Nick Banks <notifications@github.com> Mon, 29 January 2018 21:38 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 67F4D12FB97 for <quic-issues@ietfa.amsl.com>; Mon, 29 Jan 2018 13:38:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 hKIlwPBfV2IJ for <quic-issues@ietfa.amsl.com>; Mon, 29 Jan 2018 13:38:36 -0800 (PST)
Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 D48E0126D0C for <quic-issues@ietf.org>; Mon, 29 Jan 2018 13:38:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=PXNBP8ER6WmuO+/Ejs7QiE5Z+Ak=; b=D5U4iUlczDxee2EW lzh/OOCzHVsxXvdIvFMyh63ZpzABi/GhJTa2Q59tiBaw9LWJEGSMrsojtdUGaMzf WpXu2ocUComZ8eGJYC5lMo94Jt8aIhtkzOgRB1cbNSIzNIBP4s4H7AclRS0ItOIx WI3dYYxl90w/WT8We1UGaGnmX00=
Received: by filter0101p1las1.sendgrid.net with SMTP id filter0101p1las1-19007-5A6F9459-9 2018-01-29 21:38:33.38453958 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0007p1iad1.sendgrid.net (SG) with ESMTP id 9tRjuMp9QlOP-G3hrDQhbQ for <quic-issues@ietf.org>; Mon, 29 Jan 2018 21:38:33.525 +0000 (UTC)
Date: Mon, 29 Jan 2018 21:38:34 +0000
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5ab7ac099a3320f67ed173ea2b7811716e0b715492cf000000011687565992a169ce0ee08745@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/725/361395362@github.com>
In-Reply-To: <quicwg/base-drafts/issues/725@github.com>
References: <quicwg/base-drafts/issues/725@github.com>
Subject: Re: [quicwg/base-drafts] Server might be unable to complete handshake due to MAX_STREAM_DATA (#725)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a6f94594e21f_1a003fbe83168f3819952e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1H2faXXSl+0MsLUP4Vx72ng1abxaIhG6uNn8 I+kSEPCP55EMDOrQyGAJbDyacvRKQk74oHURqMsGAIIUgSYkxMhy1b+jjEOLO6dVHNUQkdX+V/Di6F /0M0gthhikA1FEwrTGMlAnZhpggOoehq7Bh0gMvLwJXgxZtKo2zNo614XHc9j5xhpcHRwuUxNo0yo0 Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/TAt0QQGyATZtWtJzgQ3tNZPhZbI>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 29 Jan 2018 21:38:37 -0000

Has there been any more progress on this front? A coworker of mine suggested another thing that we should take into account: OCSP stapling. That would further increase the size of the server's payload.

I feel like, at least for v1, we should have a way to make progress in these scenarios, even if we lose out on 0-RTT. @MikeBishop's suggestion make sense:

> "If it can't fit in N times the size of the client's packet, server MUST do source address validation before performing the large handshake."

But it doesn't fix the issue the server being blocked on the client's initial FC window. Maybe we always do a stateless retry if the server detects this issue and somehow communicates the minimum FC window size required in the retry?

-- 
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/725#issuecomment-361395362