[quicwg/base-drafts] Server's first flight should be capped by INITCWND (#3639)

Kazuho Oku <notifications@github.com> Sat, 09 May 2020 01:45 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 A62ED3A0745 for <quic-issues@ietfa.amsl.com>; Fri, 8 May 2020 18:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 yRD61W9_Y3pk for <quic-issues@ietfa.amsl.com>; Fri, 8 May 2020 18:45:15 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5203A060D for <quic-issues@ietf.org>; Fri, 8 May 2020 18:45:15 -0700 (PDT)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net [10.52.25.102]) by smtp.github.com (Postfix) with ESMTP id 3B6922C0EC5 for <quic-issues@ietf.org>; Fri, 8 May 2020 18:45:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588988714; bh=hJCv0eAdZWLaHrzRtAcwu/3TLNNsOM06TaBMtTI6pmo=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ZpWpGq3DfU1oNwp+YzeTDsAEw8vVDiRZ5I3fKS/lnSGtP0RVReXGXEeEWRGcQA27m Rru8A1wJKIZ1aEnyXxjzsNs2hGFB5+uWIhCYHv+Hqe51vHY8+tRXuO7ZK3SqiKLDeU yKcAXELO4jJtZ+EqiKo2Lt5m++h4SQms8B8AzG+8=
Date: Fri, 08 May 2020 18:45:14 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5ACGJQ6DKVCPULIMN4YHWCVEVBNHHCJKJEKY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3639@github.com>
Subject: [quicwg/base-drafts] Server's first flight should be capped by INITCWND (#3639)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb60b2a2e4c2_6aed3fb30b8cd9647798a"; 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/y9_UeXmoUQJrsyrVYyeI9DuOeJw>
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: Sat, 09 May 2020 01:45:19 -0000

When the client has a large first flight (post-quantum, or 0-RTT), it can send 10 packets at once.

But that does not mean that the server can immediately send as much as 3x it receives in response, because that is above the INITCWND - the initial assumption about the network capacity.

Things to be considered here are:
* Server cannot rely on CC until the client's address is validated, because an attacker might spoof Initial ACKs
* At the very least, server needs to send one Initial in response to every client Initial packet _not_ containing ACKs, otherwise the handshake might fail when there is hevy loss.

Based on this observation, to me it seems that the easiest way of going forward would be to state that the amplification limit changes from 3x to 1x once the amount of data being sent by the server reaches INITCWND.

Disclaimer: this issue popped up while trying to find out a response to @rmarx's claim that quicly sends 3x that is above INITCWND, when the client sends a large amount of 0-RTT data.

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