IETF Logo Mail Archive

kMaxDatagramSize

Timo Völker <timo.voelker@fh-muenster.de> Mon, 16 September 2019 06:10 UTC

Return-Path: <timo.voelker@fh-muenster.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DF81200FD for <quic@ietfa.amsl.com>; Sun, 15 Sep 2019 23:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 Cb9NU9fLHfHB for <quic@ietfa.amsl.com>; Sun, 15 Sep 2019 23:10:00 -0700 (PDT)
Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7E1202A0 for <quic@ietf.org>; Sun, 15 Sep 2019 23:09:59 -0700 (PDT)
Received: from fhad-ex03.fhad.fh-muenster.de (unknown [10.40.11.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.fh-muenster.de (Postfix) with ESMTPS id 55118284870 for <quic@ietf.org>; Mon, 16 Sep 2019 08:09:57 +0200 (CEST)
Received: from fhad-ex04.fhad.fh-muenster.de (10.40.11.27) by fhad-ex03.fhad.fh-muenster.de (10.40.11.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 16 Sep 2019 08:09:57 +0200
Received: from fhad-ex04.fhad.fh-muenster.de ([fe80::c97a:37b6:5abe:2799]) by fhad-ex04.fhad.fh-muenster.de ([fe80::c97a:37b6:5abe:2799%2]) with mapi id 15.01.1713.006; Mon, 16 Sep 2019 08:09:57 +0200
From: Timo Völker <timo.voelker@fh-muenster.de>
To: "quic@ietf.org" <quic@ietf.org>
Subject: kMaxDatagramSize
Thread-Topic: kMaxDatagramSize
Thread-Index: AQHVbFVdRbSFEGtdaEer3um4O+4Bdw==
Date: Mon, 16 Sep 2019 06:09:56 +0000
Message-ID: <08A80917-B4B7-49B2-8695-790AFFC6866C@fh-muenster.de>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.40.10.31]
Content-Type: multipart/signed; boundary="Apple-Mail=_A20631E8-98A2-4A8E-9ABB-61ECEA23EEF5"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/XmuIFAFx9GZCpm6i6iAuMFnzIKA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 06:10:03 -0000

Hi,

I wonder why kMaxDatagramSize is a constant and why the recommended value is 1200 (section B.1. of the recovery draft).

The transport draft mentions PMTUD, which makes the QUIC maximum packet size variable.
Also it mentions that, in absence of a PMTUD, we can assume a QUIC maximum packet size of 1232 or 1252 for IPv6 or IPv4, respectively. Why is 1200 bytes recommended then?

My assumption is that kMaxDatagramSize = QUIC maximum packet size. Is this just wrong? Is it OK to use a kMaxDatagramSize with kMaxDatagramSize <= QUIC maximum packet size?

Thanks,

Timo

v2.23.0 | Report a Bug | By Email