IETF Logo Mail Archive

[quicwg/base-drafts] max_udp_payload_size during the handshake (#3638)

David Schinazi <notifications@github.com> Sat, 09 May 2020 01:14 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 1943D3A0418 for <quic-issues@ietfa.amsl.com>; Fri, 8 May 2020 18:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level:
X-Spam-Status: No, score=-1.552 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_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 vo9bshgwGVcA for <quic-issues@ietfa.amsl.com>; Fri, 8 May 2020 18:14:27 -0700 (PDT)
Received: from out-27.smtp.github.com (out-27.smtp.github.com [192.30.252.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A613A0400 for <quic-issues@ietf.org>; Fri, 8 May 2020 18:14:27 -0700 (PDT)
Received: from github-lowworker-cde56e0.va3-iad.github.net (github-lowworker-cde56e0.va3-iad.github.net [10.48.25.52]) by smtp.github.com (Postfix) with ESMTP id 10A57E0F5C for <quic-issues@ietf.org>; Fri, 8 May 2020 18:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588986865; bh=LJd+0Ghlo549YnrbRUsTImCVl6MwqK/xechy0FMTjX8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=CW8OLowigDZ5wE6pILlMEDWH4dp+fN+8TLYt4yFT1bMK3SONzddGqMvxdDgr94y4b lnnqNAykDJMbETMWAgJ5aTkscqZQbR35/U7jC7YCV0Vv51XKAu0RiodlaDCj6+6+j5 GyJf39FGmoIMyS47X23mWcOlco+Oh/IlKu3KPwcc=
Date: Fri, 08 May 2020 18:14:25 -0700
From: David Schinazi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK733JELKRNAJYRMGG54YHSPBEVBNHHCJKIRDE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3638@github.com>
Subject: [quicwg/base-drafts] max_udp_payload_size during the handshake (#3638)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb603f1a5e_653a3f8a8eacd96c856ef"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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/ELTxzcXy6C2oIVW_tqLjA7u9T9c>
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: Sat, 09 May 2020 01:14:29 -0000

The `max_udp_payload_size` transport parameter (formerly known as `max_packet_size`) instructs the receiving endpoint that it should try to avoid sending packets bigger than that number. However, some packets are sent before the transport parameters are received. Should the draft contain some guidance about what value to use during the handshake? Our implementation currently uses a default value of 1350 until the transport parameters have been received, and I wonder if that may lead to interop issues if some Web servers implement QUIC but drop packets larger than 1300 for example. One could consider using the minimum possible value (1200) during the handshake but I fear that this would negatively impact performance.

-- 
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/3638

v2.23.0 | Report a Bug | By Email