Re: [quicwg/base-drafts] Remember UDP size limit for 0-RTT (#3498)

Martin Thomson <> Wed, 04 March 2020 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE8443A104E for <>; Tue, 3 Mar 2020 23:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QiyA8wLb0NPz for <>; Tue, 3 Mar 2020 23:00:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76D5C3A104A for <>; Tue, 3 Mar 2020 23:00:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6D4AAA04F7 for <>; Tue, 3 Mar 2020 23:00:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583305216; bh=GvTUzBF72WS/QGM9sqWLcobXfZfnTiLhtWtVl1j4EdY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ddwPiehER8ZKlzOM/A7/Lb3ZNQv1S1P6BJy392LYkQowEXHMylkuHdOOYnDLg/893 JEiYMefq+iDovYau+7mfBHJ4XmIGC3PTyNjBYKKm3eeIJ1kR3WDYH6QS6tAq/bYWO5 /l751XO2EDov2ycmeH3LKUK4BtYfodojp0CZONk0=
Date: Tue, 03 Mar 2020 23:00:16 -0800
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3498/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Remember UDP size limit for 0-RTT (#3498)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e5f52005ebda_2b603ff9914cd96435772d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2020 07:00:19 -0000

martinthomson commented on this pull request.

 * initial_max_data
 * initial_max_stream_data_bidi_local
 * initial_max_stream_data_bidi_remote
 * initial_max_stream_data_uni
 * initial_max_streams_bidi
 * initial_max_streams_uni
+* max_udp_payload_size

You are suggesting then that this can work in certain narrow cases, therefore it shouldn't be a firm requirement?

The inverse of that is that is what concerns me.  Servers accept 0-RTT with reduced limits, with reasons other than the ones you describe, and all of the 0-RTT goes into the void.  Clients will routinely attempt to fill all available 0-RTT space with data.  If the limits that the server imposes matter here.

If local constraints change in a way that the server knows about, such that it will advertise a lower limit in the transport parameter, then it is better if it doesn't accept 0-RTT.

I get that this is a "no harm" scenario in the sense that the connection won't be torn down as a result of all those packets getting lost, but the result is worse than rejecting 0-RTT because the client will mark all those packets as lost as opposed to just forgetting them.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: