IETF Logo Mail Archive

Re: Space for Packet Metadata

Christian Huitema <huitema@huitema.net> Wed, 28 February 2018 15:19 UTC

Return-Path: <huitema@huitema.net>
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 94DE412D94B for <quic@ietfa.amsl.com>; Wed, 28 Feb 2018 07:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 s1h0E_iN46TB for <quic@ietfa.amsl.com>; Wed, 28 Feb 2018 07:19:26 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D2312EB23 for <quic@ietf.org>; Wed, 28 Feb 2018 07:19:26 -0800 (PST)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx62.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1er3Vm-000Ajl-4M for quic@ietf.org; Wed, 28 Feb 2018 16:19:18 +0100
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1er3Vh-0005HL-Dy for quic@ietf.org; Wed, 28 Feb 2018 10:19:16 -0500
Received: (qmail 20294 invoked from network); 28 Feb 2018 15:19:11 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 28 Feb 2018 15:19:11 -0000
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "Eggert, Lars" <lars@netapp.com>
Cc: IETF QUIC WG <quic@ietf.org>
References: <CAN1APdfx4Y4MUm5iAF99Vn1Svck5y2e6_qrNbozkwJWics17eQ@mail.gmail.com> <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> <CAN1APddJJHrpKBjn+U=rYYzxnuwyRYvA3++0T_ZRMy15fCJgbQ@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <be1e686d-a5d6-1b03-fb69-5dcc9f677612@huitema.net>
Date: Wed, 28 Feb 2018 07:19:09 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAN1APddJJHrpKBjn+U=rYYzxnuwyRYvA3++0T_ZRMy15fCJgbQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CCFEB3DDE7B2DA685D29C32A"
Content-Language: en-US
Subject: Re: Space for Packet Metadata
X-Originating-IP: 168.144.250.177
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5h88zKHxrliKrY8XNzN5pO1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViXpz0dH/WxyU/dajMfNk5Zs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQY5T+fsIz86TG72Lx5ZI1p INh8UHPssUrY3MbbkBcNcJO9YzGWVp9p+Opk9w8BAh9BxI/M6J4yAZL75BrNNq2wthpBOi7IfT+J o+6tsQI5W/ewkYi/XXej6UeAUN96sXI71lsFqhWb3P21BZ9jlHPbPCpCZDzbriLb09ArJ34XSivy hX2xfGWtxArAagg2yIWQOB6kNh2xMmXEi/DfgKmivtduw1uWwE7LyoeeLDBQmE9c9aUV1oY4fX3W 5eOCNA395VKQZZ28EUZBFBO/fNvHx7hwG59VyR4YOQV4JnKL5mXuymSkQySlRRw9754xJI2l7TrO wPFJd4XqI4y6kTdZJ/Tgs5pdKJpNpy9rpzw+UwWR2z7Rjs3BT1o4+6YSC6IfVgW9/bktU41htiJ8 fk7NkCSgONC3rqaXJrYXVXXByjf4baeCkx0hN8MDgAhE+CBnCUTZMc2PfI2VFTu1YYhfjg==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DUDWIHZZvnCLGpE30Xev2yXPwEc>
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 15:19:29 -0000


On 2/28/2018 7:03 AM, Mikkel Fahnøe Jørgensen 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.
>
> I’m not saying it can’t work, rather I'm asking because I don’t think so.
>
> On 28 February 2018 at 15.58.39, Eggert, Lars (lars@netapp.com
> <mailto:lars@netapp.com>) wrote:
>
>> any such servers can already "reserve" such space by not forwarding
>> packets that exceed whatever limit they want to enforce - this is how
>> PMTUD works. 

What Lars said. If networks want to play game with extra forwarding
overhead, they have to ensure that they can tunnel a min MTU packet,
i.e. 1280 bytes. Which is not a problem since the local MTU is generally
1536 bytes, and there is no practical reason to have more than 200 bytes
of overhead.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email