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

Kazuho Oku <notifications@github.com> Fri, 21 February 2020 05:10 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 4C2C7120639 for <quic-issues@ietfa.amsl.com>; Thu, 20 Feb 2020 21:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 Rqj1jO77uZQN for <quic-issues@ietfa.amsl.com>; Thu, 20 Feb 2020 21:10:44 -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 12466120236 for <quic-issues@ietf.org>; Thu, 20 Feb 2020 21:10:44 -0800 (PST)
Date: Thu, 20 Feb 2020 21:10:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1582261843; bh=nSkavc90MnUNUeY786i6qpCHvgvxROfRIqzb9F5Jl+M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Z5V1R7d0n3QyyOvKHDvJMwYCAcgpnopylsB9bpdAEgQkty1iGubfFkjGs36vAcjbS CxC7WXIdTsiINkzGbBSBSQy9CdCRB6lGPqWbeX1WCcLmW9FrgWGW571yDvN4tJZIue JP3MzyLJKO97DNA/xJqeuTNV+4CbA8K5yLrbswtg=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZDD5KY7XHV7JHEIZV4LSMNHEVBNHHCDDCFOU@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/589501315@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_5e4f66531d6d7_20803fe9e3ccd9609816c"; 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/JwHhYxJyNP0uUv3lYc4878Nuooo>
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: Fri, 21 Feb 2020 05:10:47 -0000

> I don't like @kazuho's proposed change. The point of this is to express a limitation of the endpoint. If the endpoint only has X bytes of memory for receiving packets, then it can use this limit. Absent this, we can't ever hope to have big endpoints talking to little ones. We will end up with middleboxes (hello CoAP).

Yes, I share the view that the sender should adhere to the receiver's advertised limit. But that does not mean that exceeding the limit needs to trigger a protocol violation, or if the receiver should be allowed to trigger that.

I might argue that, in practice, receivers would not trigger protocol violation when it receives a QUIC packet that is larger than the advertised maximum. This is because the receiver has to decrypt the packet that is larger than its limit in order to check that the packet was not spoofed. But is there an incentive to have a buffer that is larger than the advertised maximum just for this purpose? I do not think so. I'd assume that endpoints would simply advertise its buffer size.

I think we just have different view points. One way of viewing this TP is that it is an ordinary TP, and therefore that when 0-RTT is being used, the resumed connection inherits this TP too from the previous connection.

The other way of viewing this TP is that it is an optimization of PMTUD, that lets a receiver advertise the maximum size of a datagram that is capable of processing. PMTUD needs to be applied per each connection (or to be precise per each path), regardless of if 0-RTT is used. If we view the TP this way, it can be considered something that kicks in when the TP is received for every connection.

IMO the latter view is simpler in terms of implementation complexity, and has no downsides.

-- 
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-589501315