IETF Logo Mail Archive

Re: [quicwg/base-drafts] max_packet_size in 0-RTT (#3447)

martinduke <notifications@github.com> Mon, 10 February 2020 22:59 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 1528D120889 for <quic-issues@ietfa.amsl.com>; Mon, 10 Feb 2020 14:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ME2oH6SxQBX5 for <quic-issues@ietfa.amsl.com>; Mon, 10 Feb 2020 14:59:38 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49303120888 for <quic-issues@ietf.org>; Mon, 10 Feb 2020 14:59:38 -0800 (PST)
Received: from github-lowworker-275fa97.va3-iad.github.net (github-lowworker-275fa97.va3-iad.github.net [10.48.17.64]) by smtp.github.com (Postfix) with ESMTP id 71A6F520026 for <quic-issues@ietf.org>; Mon, 10 Feb 2020 14:59:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581375577; bh=Tu/QHlrFq7Cs52xiTlKzbGxcEL2PoldnqwABwLYRzwY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cD7al1R+l3kwzlECNzRe3pTh7MCmKVQkxBrvAyh96ZoEMO5zgz4Py0U5kAnLiAcoE +9qpOOux0JI603lBe/i6lIoTh11RjQu/t/xVQxjEfjK1KB5GB9dX8JEw2e3q3rJSXw AgpQ00BBaaW4iHkxA8badAs0mlO3EC5DKsNJvUhc=
Date: Mon, 10 Feb 2020 14:59:37 -0800
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5XSIN6BUHZDH2ECYF4J4JNTEVBNHHCDDCFOU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3447/584399944@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3447@github.com>
References: <quicwg/base-drafts/issues/3447@github.com>
Subject: Re: [quicwg/base-drafts] max_packet_size in 0-RTT (#3447)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e41e059628fb_26e33fd57fccd9604203f"; 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/Tu5FRT4rI6ylajulneggVI2qucg>
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: Mon, 10 Feb 2020 22:59:40 -0000

I will note that we already had this discussion in #2467 (and it was the two of us!)

What are the use cases where max_packet_size would change?
- the server interface has changed and can't accept these anymore -- I would think this was de facto going to result in not accepting 0RTT if the packets were too large. I'm not sure why we would reject 0RTT packets that happened to fall under the new limit, in this case.
- the max_packet_size is being set for some other reason -- perhaps to match an MTU on the other side of a proxy, to reduce copying. Again, as a proxy implementer I'd probably take the data but dictate that future packets be correctly sized.

Is there some other use case I'm not aware of?

-- 
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/3447#issuecomment-584399944

v2.27.8 | Report a Bug | By Email | System Status