Re: Proposal: Increase QUIC Amplification Limit to 5x
Matthias Waehlisch <m.waehlisch@tu-dresden.de> Tue, 30 July 2024 21:48 UTC
Return-Path: <matthias.waehlisch@tu-dresden.de>
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 21334C14CF12 for <quic@ietfa.amsl.com>; Tue, 30 Jul 2024 14:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39wHsNy6U8Rx for <quic@ietfa.amsl.com>; Tue, 30 Jul 2024 14:48:17 -0700 (PDT)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716D3C14CE53 for <quic@ietf.org>; Tue, 30 Jul 2024 14:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-ID:Content-Type:MIME-Version: References:Message-ID:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S52KGo6/TFbEu2XWOH4qHV64ScC+M7vXb5uEoeTOA00=; b=FS6+mz3bQlxTMjad5A2PXrEsPN XkNHBid1QrKLIZSfyuhijE/pz4DZ3NieLhIByWXzauojxU950m8d33D/IEqIhSYe4kDGt+gxG28to Hn2S0RXiD5gTCaY7VXNafyrFoYR1x3r1pzaDi0rfoT/esgJht7F+14Td4XGXPkSHw8tsqC88Dak+B GVfRJVwguQlitEfclAyDEHEPU9D2qLNhWfCLqfQ70s/7oCA4HTlnPk2H4mvrhnbpJjDNrMV/+TyiP sSBqPU8GGpHRbS/RKSxaCx/iX8wOGf2K4Vvv6975c4cAC7Z2U7uU9TKHsGu6zX1oNW88pJKE7MT5c 6OxQrNiw==;
Received: from [172.26.34.111] (helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <matthias.waehlisch@tu-dresden.de>) id 1sYuHw-008Ss2-W5; Tue, 30 Jul 2024 23:21:45 +0200
Received: from mw-x2.fritz.box (77.191.156.179) by MSX-L311.msx.ad.zih.tu-dresden.de (172.26.34.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 30 Jul 2024 23:21:34 +0200
Date: Tue, 30 Jul 2024 23:21:32 +0200
From: Matthias Waehlisch <m.waehlisch@tu-dresden.de>
To: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>
Subject: Re: Proposal: Increase QUIC Amplification Limit to 5x
In-Reply-To: <BL1PR21MB31152570F4497EBE91B3AF9FB3B02@BL1PR21MB3115.namprd21.prod.outlook.com>
Message-ID: <9dd0180c-7b3a-0ae1-3984-dc9fa39fc66d@tu-dresden.de>
References: <BL1PR21MB31152570F4497EBE91B3AF9FB3B02@BL1PR21MB3115.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="33020704-15811-1722349464=:16692"
Content-ID: <839a9dad-65f6-caa9-28c6-4e81b4236eb5@link-lab.de>
X-ClientProxiedBy: MSX-L311.msx.ad.zih.tu-dresden.de (172.26.34.111) To MSX-L311.msx.ad.zih.tu-dresden.de (172.26.34.111)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: CUF7YS72A7L57MTJEZRFFPL2SLICU4FY
X-Message-ID-Hash: CUF7YS72A7L57MTJEZRFFPL2SLICU4FY
X-MailFrom: matthias.waehlisch@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-quic.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "quic@ietf.org" <quic@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AquWjXaiiluyepDKZ3VVgNik4A4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Owner: <mailto:quic-owner@ietf.org>
List-Post: <mailto:quic@ietf.org>
List-Subscribe: <mailto:quic-join@ietf.org>
List-Unsubscribe: <mailto:quic-leave@ietf.org>
Hi Nick, personally, i'm still more in favor of getting certificate sizes smaller instead of increasing the amplification limit, since unnecessary large certificates are the major problem [1]. cheers matthias [1] https://dx.doi.org/10.1145/3555050.3569123, preprint available on https://arxiv.org/pdf/2211.02421 On Tue, 30 Jul 2024, Nick Banks wrote: > > Hello Folks, > > > > We’ve had this discussion on Slack in the past, and I wanted to bring it here > to get some additional feedback. As some of you know, I have a project on > GitHub (microsoft/quicreach) that is a simple ping-like reachability tool for > QUIC, and I run a periodic action to test the top 5000 hostnames for > QUIC-reachability and then breaks the handshake down by whether it (a) > requires multiple round trips, (b) exceeds the specified amplification limit > or (c) connects in 1-RTT under the limit. It produces this dashboard: > > > > [IMAGE] > > > > The main point in sending this email is to focus on the large percentage of > servers that are ignoring the 3x amplification limit today, and what we should > do (if anything) about that. I ran a quick experiment (PR) this morning to > test how the breakdown would look if we had different amplification limits > (3x, 4x, 5x) and found that if we used a 5x limit we would find ourselves in a > place where most servers are now under the limit. > > > > [IMAGE] > > > > So, my ask to the group is if we should more officially bless a 5x limit as > ‘Ok’ for servers to use. This would more impact those servers that currently > take multiple round trips because they are correctly enforcing the 3x limit on > themselves, resulting in longer handshake times. If we say they can/should > change their logic from 3x to 5x, then their handshake times will improve, and > largely things will speed up for clients when using QUIC. Personally, I’d like > to update MsQuic to use this new limit based on this data, but I wanted to get > a feel from the group first. > > > > Thanks, > > - Nick > > > > Sent from Outlook > > > -- Matthias Waehlisch . TU Dresden, Chair of Distributed and Networked Systems .. https://tu-dresden.de/cs/netd/about/mw
- Proposal: Increase QUIC Amplification Limit to 5x Nick Banks
- RE: Proposal: Increase QUIC Amplification Limit t… Nick Banks
- Re: Proposal: Increase QUIC Amplification Limit t… Matthias Waehlisch
- Re: Proposal: Increase QUIC Amplification Limit t… Paul Vixie
- Re: Proposal: Increase QUIC Amplification Limit t… Christian Huitema
- Re: Proposal: Increase QUIC Amplification Limit t… Ian Swett
- RE: Proposal: Increase QUIC Amplification Limit t… Nick Banks
- Re: Proposal: Increase QUIC Amplification Limit t… Martin Thomson
- Re: Proposal: Increase QUIC Amplification Limit t… Roberto Peon