IETF Logo Mail Archive

Re: [quicwg/base-drafts] Remembering transport parameters (#3434)

martinduke <notifications@github.com> Tue, 25 February 2020 15:53 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 470ED3A0F5F for <quic-issues@ietfa.amsl.com>; Tue, 25 Feb 2020 07:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
X-Spam-Status: No, score=-1.696 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 kQzlrCcHKPli for <quic-issues@ietfa.amsl.com>; Tue, 25 Feb 2020 07:53:16 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BC93A0F61 for <quic-issues@ietf.org>; Tue, 25 Feb 2020 07:53:15 -0800 (PST)
Received: from github-lowworker-39b4a70.va3-iad.github.net (github-lowworker-39b4a70.va3-iad.github.net [10.48.16.66]) by smtp.github.com (Postfix) with ESMTP id A5F692C210E for <quic-issues@ietf.org>; Tue, 25 Feb 2020 07:53:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1582645994; bh=HVhd552kOC7JcwSn7nGO/nqNZw/yvfoW9cuiQzOgW4k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=l1xv+130bsdxw61iYvtXEszkc88j/EkHSMQxI2NsNrf06hcmxrJAPKnlPDWJWTdpL LK5+cL/HUZuvT1WrCslLhsrYZD6y2ThqrrXFSlqIVCDJf/O6VacM9XGbbP5+DZEeoZ YDJ1veSOCAvemBu/qLiyHHGWqtAD6LRZBzDAiw+M=
Date: Tue, 25 Feb 2020 07:53:14 -0800
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYLWUOKI2U37WCHNIN4MJ2WVEVBNHHCC3UEJM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3434/590936990@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3434@github.com>
References: <quicwg/base-drafts/issues/3434@github.com>
Subject: Re: [quicwg/base-drafts] Remembering transport parameters (#3434)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e5542ea94173_5d003f85af8cd95c16181"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/uuZovr6pvSKpZR3WQLvVU4vbuwk>
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: Tue, 25 Feb 2020 15:53:19 -0000

@martinthomson I have trouble seeing why this isn't safe.

Let's say that we change the rule to say that servers MUST reject 0RTT if max_udp_payload_size has decreased. Then the client will send its Initial, plus a bunch of 0RTT, and then get a server extension that indicates that the server isn't accepting early data. A sensible congestion controller will then disregard the inevitable 0RTT packet losses.

If we allow 0RTT in this case, the client will send the same thing. The server doesn't get, or chooses to drop, any datagram that exceeds the new max size. A sensible congestion controller will see the updated TP and disregard 0RTT packet losses that exceeded the new max size.

The second scenario doesn't strike me as any more problematic than the other.

-- 
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/3434#issuecomment-590936990

v2.23.0 | Report a Bug | By Email