Re: Space for Packet Metadata

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 28 February 2018 16:04 UTC

Return-Path: <mikkelfj@gmail.com>
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 C632312D0C3 for <quic@ietfa.amsl.com>; Wed, 28 Feb 2018 08:04:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7Y6F3YXqOuTa for <quic@ietfa.amsl.com>; Wed, 28 Feb 2018 08:04:36 -0800 (PST)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0955124B17 for <quic@ietf.org>; Wed, 28 Feb 2018 08:04:36 -0800 (PST)
Received: by mail-it0-x22d.google.com with SMTP id l187so4112488ith.4 for <quic@ietf.org>; Wed, 28 Feb 2018 08:04:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=6ZTCBxyKbsDQPamsFyjyNXArr0pi3zO2SFjD7elK/uQ=; b=qmMJnc7gR3VF0k6pUhJiTzsC7ejqKMSlfrTlIJj19OStLE9JNvxPZ8HNrnYQz4ZWHO DH3SY0VnmOE4lfcLTh1Wao/+S5WDBqmoqgxx6bG7j8d8SDVsV4p6bqvKnMhRDs98GIPu nUbSJCnNQg+sw4beRwLfZ1FwiSTMf53gBLicFaVo+Kzzt84IPNgkKi1ieByMghVOvnln aN53WIz2tagMgqFLb/YOQGR7yqNhe97KGlRI5Z1guSdcnx/03fdfcTezEi5M+5TtNdgQ ZQJuPe6IwIDcGyvwpmCnrtdMErVaGQlU1hQBdJIu5pHW76lrlsLs0cOf8dFWqSJQcRfY evIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=6ZTCBxyKbsDQPamsFyjyNXArr0pi3zO2SFjD7elK/uQ=; b=AfbazyNeTvM6wEu0JJeMGz28SvbYTndvcFMeElCaSvCAC9kiEearqYjdax0l5fX0/L 88K4u6ECS6JuW8fcbzpDiL/nrcJB5n/EN47Nirlr6ihKZkiNu6lWJRWsqNlL1ZBKnhtm 2qcTv2LZiAE1v5afi0CKLkojmEuZ4nHmb5MP3uOBiVLViQmGc/is5wV8YTlbdQYiSHFR BHn03M8MPRzU1nTK8+cOzcvpAF77lmvyVp8mKLLz2O5jGN85qxQ4p6fMBcIH788L8dFm pUAvYNosR5Y5gQpiPRfkxv94lnE7vIf7NR0jJYrV/87GGIESHgTE7SLaACaitiC33xRu 4mOA==
X-Gm-Message-State: APf1xPA3+vOAVU7h12tvqCKvfzXEaDFpz/rMTXMTN8o6C7C+ye1eD24/ VYNlIVIb/pJwP/6o39K5d42Y3lGZTobwDE4J2U8=
X-Google-Smtp-Source: AG47ELudbZBTmaobNJbpO2ouqM5dhNMw6jTZpdSQrAVnvs5VrliHeP4W5VSqN75hozg+NO/KjH10kQKZx21AyIYgnwM=
X-Received: by 10.36.90.212 with SMTP id v203mr2355851ita.150.1519833876076; Wed, 28 Feb 2018 08:04:36 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Feb 2018 08:04:35 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <5DB55652-7509-4026-B678-30EACFEB6380@lurchi.franken.de>
References: <CAN1APdfx4Y4MUm5iAF99Vn1Svck5y2e6_qrNbozkwJWics17eQ@mail.gmail.com> <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> <CAN1APddJJHrpKBjn+U=rYYzxnuwyRYvA3++0T_ZRMy15fCJgbQ@mail.gmail.com> <FC9963A9-F5B4-4A4B-8DE9-FB938B390BB0@netapp.com> <DM5PR2101MB09010484CA0782C13E43C2C4B3C70@DM5PR2101MB0901.namprd21.prod.outlook.com> <5DB55652-7509-4026-B678-30EACFEB6380@lurchi.franken.de>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 28 Feb 2018 08:04:35 -0800
Message-ID: <CAN1APddTgkpTBQ9ipGxTm8KJhrcxwwy-ZW=6ivjgSrJjOiw5Qw@mail.gmail.com>
Subject: Re: Space for Packet Metadata
To: Nick Banks <nibanks@microsoft.com>, Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: IETF QUIC WG <quic@ietf.org>, "Eggert, Lars" <lars@netapp.com>
Content-Type: multipart/alternative; boundary="001a1143b9b04d2184056647e6dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/uW4lgZleRirD17qAEqzbhgN9i70>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 28 Feb 2018 16:04:39 -0000

https://blogs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues

IPV6 UDP overhead is 48 bytes
https://en.wikipedia.org/wiki/User_Datagram_Protocol

Minimum expected PMTU is 1280 bytes (and required by QUIC)
Local MTU expected 1536 bytes

1536 - 48 = 1488
1488 - 1280 = 208 bytes

So there is already 208 bytes reserved for tunnelling etc. Which is fine.
Exactly what I was asking for.


On 28 February 2018 at 16.55.05, Michael Tuexen (
michael.tuexen@lurchi.franken.de) wrote:

> On Feb 28, 2018, at 4:30 PM, Nick Banks <nibanks@microsoft.com> wrote:
>
> According to spec, QUIC requires at least 1280 (from 9.4):
>
> "QUIC depends on the network path supporting a MTU of at least 1280
octets. This is the IPv6 minimum MTU and therefore also supported by most
modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this
number, even if it receives signals that indicate a smaller limit might
exist.'
When discussing safe MTU values for WebRTC, 1280 for IPv6 was acceptable,
but not for IPv4. After a discussion,
the suggested value for IPv4 was 1200. See
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5

Not sure what changed in between...

Best regards
Michael
>
> - Nick
>
> -----Original Message-----
> From: QUIC <quic-bounces@ietf.org> On Behalf Of Eggert, Lars
> Sent: Wednesday, February 28, 2018 7:12 AM
> To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
> Cc: IETF QUIC WG <quic@ietf.org>
> Subject: Re: Space for Packet Metadata
>
> On 2018-2-28, at 16:03, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
wrote:
>> Yes, but can it go below 1200? It seems the handshake aims to squeeze up
near the minimum guaranteed (required) PMTU and QUIC implementations would
probably not expect to maintain a connection that drops below PMTU 1200.
>
> The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as least
that low.
>
> Lars