[quicwg/base-drafts] Change max_packet_size to max_datagram_size (#3471)

Kazuho Oku <notifications@github.com> Thu, 20 February 2020 14:12 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 319E012003E for <quic-issues@ietfa.amsl.com>; Thu, 20 Feb 2020 06:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TnXbeElmrtmY for <quic-issues@ietfa.amsl.com>; Thu, 20 Feb 2020 06:12:23 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B990A1200D5 for <quic-issues@ietf.org>; Thu, 20 Feb 2020 06:12:23 -0800 (PST)
Date: Thu, 20 Feb 2020 06:12:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1582207942; bh=zhr0ivQm9fcTQDtBsK9jWIVHAeKDz++1hOBZ2rq2Vjw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=xhLGQRyRw84j1EnY0sQxYqe3cUpw8HfW1Iiqw1h1W42gCycxyb9CFpKvUgTbanJv3 J6jjMWe+8MYsYsZwGPX2Y8Qo7wRCwaa7RVOSoPvvcsS9T+a2IaZdTX/8Bd1Zs0ArQC OvBRGJK3WE9/rOHrin6UvNMTDdqgRrON4lu7egTA=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3FAH4YUKCXPRO2PQ54LPDENEVBNHHCDYABKU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3471@github.com>
Subject: [quicwg/base-drafts] Change max_packet_size to max_datagram_size (#3471)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4e93c65f75f_10f53ff74b4cd95c14406a"; 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/G2d7t8LIKmBWSSnL21iTVEme5Fs>
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: Thu, 20 Feb 2020 14:12:25 -0000

At the moment, the max_packet_size Transport Parameter is a size limit of "a packet," and we seem to interpret that it means "a QUIC packet." I am not sure if that has been our intent.

IIUC, the reason we have this TP is to tell the peer the maximum size of a "UDP datagram" that the endpoint can handle. Not the maximum size of a "QUIC packet."

The problem with having this limit being defined at QUIC packet-level is that it allows the sender to send a coalesced packet that consists of multiple QUIC packets, each of them consuming max_packet_size bytes.

For example, when responding to a client-sent Initial, a server is allowed to send a coalesced packet containing one Initial, one Handshake, one 1-RTT packet, each of them in full size, and expect the client to not drop the coalesced packet, assuming that the network can handle jumbo packets<sup>1</sup>.

This means that a QUIC stack needs to be prepared of handling UDP datagrams at most `3 * max_packet_size` bytes.

I do not think we would want to do that. Therefore, the proposal is to change the definition of the TP from max_packet_size to max_datagram_size.

As an alternative, we can change it to max_ip_packet_size, but considering the BSD socket API, I think that max_datagram_size would be a more natural fit.

[1] Note that there is a performance incentive to configure QUIC endpoints to send jumbo packets.

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