IETF Logo Mail Archive

RE: Space for Packet Metadata

Praveen Balasubramanian <pravb@microsoft.com> Sat, 03 March 2018 18:55 UTC

Return-Path: <pravb@microsoft.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 91F76126CD6 for <quic@ietfa.amsl.com>; Sat, 3 Mar 2018 10:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 GECrzoMotpQG for <quic@ietfa.amsl.com>; Sat, 3 Mar 2018 10:55:01 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0116.outbound.protection.outlook.com [104.47.33.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31043126CB6 for <quic@ietf.org>; Sat, 3 Mar 2018 10:55:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mpUdYpk+KThHctJ8IEZ0gz46WuN3U2f0UxCmwueWvKc=; b=LX8gBJmo5LW7jO1NIT5+wyPum15bqPAPjSUlxzbXsKSJnNRYgtDtaFgNyo1qKitysZI1mwiQv3gha1YIcm/GcN3knvkkpvTKl4mUeQjEZdsRsiJ/Dwe04xRRg660Q4C54BtCwuh2yBVv5ZJlwx3u32mKlKhjSnjHPfZGS/nsoQI=
Received: from CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.588.1; Sat, 3 Mar 2018 18:54:58 +0000
Received: from CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::1ccf:93aa:3263:987]) by CY4PR21MB0630.namprd21.prod.outlook.com ([fe80::1ccf:93aa:3263:987%2]) with mapi id 15.20.0567.006; Sat, 3 Mar 2018 18:54:58 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Nick Banks <nibanks@microsoft.com>
CC: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, "Eggert, Lars" <lars@netapp.com>
Subject: RE: Space for Packet Metadata
Thread-Topic: Space for Packet Metadata
Thread-Index: AQHTsGvSsrICpCIcBkuus0WfleDWv6O56EKAgAABiYCAAAJ2gIAABQCAgAAKLoCABOU6sA==
Date: Sat, 03 Mar 2018 18:54:58 +0000
Message-ID: <CY4PR21MB0630399F691CCDD4BE128043B6C40@CY4PR21MB0630.namprd21.prod.outlook.com>
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> <5A96D399.4010300@erg.abdn.ac.uk>
In-Reply-To: <5A96D399.4010300@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:5::97]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 6:rDafSn60BD1cktUXeNPjdkSWNbwGtkC8b0TLp/t744gsphtrb8U9zfnMPCKSBE9B+aWMl6lSr5bLXasD/yw910vXd2iVsg4Mu28/RFwYkUuBkHmOr646JqdB1u9xku3uf9qhVK9djsqr+m9juetVEVYwh+EkYOqGASXNclwnHFjnXZ1JVRMwSqqmmvf1jlxuU5UPQpwCLnuuTXZswjv2KIW9HiYgebvcKxet6XbeaQvbUkQofRLPQc1xOSSZqM6GOs4CcJc6D/YLLVzBHtGNhnG2YU6bFG17rLfQHwjlwdicD1aEiNzx8DUth7i9nSDp/DaZHl8dFLSZ0JSoYZRvl/vfbyFI3HZ6RzZiY4C1vTR25AN7IqlYAlluTHTh/cGE; 5:57BxRtI2SpTErpgAusMkfbnODX/0MwMGYg6HhpjGgbXe3YGAiTjGljjIU46vojFxnRWeUW0abvy1SsjF7f9VNDxEELGrzDDhi4A8CMv+jCk6QOJWkGFtiWXhdCpyr5pJeOnLmB8k4JQ++paUcKdURBIzLaNEyE4rksI1G7vHA+4=; 24:ioyh72xy/xgGdYGmSRYTtHQhJMtMz3/C+9h+XhrYjVTVXeowoo9ubKfoHMhal7fVt7yflEjJxx5LXxClWKqZUHNgZ0s5bdUhHGvgu7nui8c=; 7:kizdVkJJDbQxMwbjz9MoUQOULczw8wv14VOJWanEJ+Y3UQ482bB82vkKC0f2N0gS2kW7PHiJ5krwj2ggF639IQMxED+NEWmAV+hs+DsNKVkReuaxH4Guh0kAzoEr/9UVzXhyv4LVTfSqYJVsKl5fP6aN4NsInG68g81ECSRtw9NJ3rUF5W2RRXU9i38gErTiSzi5dK40Uo6rRY5Rla6S7iYcX6ketpwBiSjc5lYJPLli2YBiC3oVZ6PIrCo1k2Pl
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b8e4f35e-32a6-49e6-3b06-08d581384317
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:CY4PR21MB0501;
x-ms-traffictypediagnostic: CY4PR21MB0501:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <CY4PR21MB0501522CB9664BD1798E7050B6C40@CY4PR21MB0501.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(189930954265078)(85827821059158)(219752817060721)(213716511872227);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123564045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0501;
x-forefront-prvs: 0600F93FE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(366004)(39380400002)(396003)(13464003)(199004)(189003)(377424004)(3280700002)(39060400002)(2950100002)(25786009)(3480700004)(99286004)(5250100002)(229853002)(1511001)(2501003)(6246003)(7736002)(4326008)(81156014)(81166006)(10290500003)(6116002)(2906002)(7696005)(6636002)(6306002)(9686003)(4001150100001)(110136005)(8676002)(97736004)(305945005)(53936002)(54906003)(2900100001)(93886005)(478600001)(46003)(6436002)(55016002)(8936002)(68736007)(14454004)(86612001)(186003)(105586002)(59450400001)(22452003)(106356001)(8990500004)(5660300001)(86362001)(575784001)(74316002)(33656002)(966005)(76176011)(3660700001)(296002)(316002)(6506007)(102836004)(10090500001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0630.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: r0nhoS0RUKQXBmKqAE0XkKTdMo68HtqYjWPAUXcAKL1SLinhRpn4YtLSdYuYfk+KWMOXT4iV7231mWpYarvOrsfBfVcMHHy4pen3FSPqVPwX3LwTMXqyNqMaChWdbcebTWhfkdyDmqcx0PnZ2o1Mum2mPg+fDDJgfsPK7wo4yTc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8e4f35e-32a6-49e6-3b06-08d581384317
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2018 18:54:58.4409 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OS56jCXxkq2--Ixrr9OxehOUHbQ>
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: Sat, 03 Mar 2018 18:55:04 -0000

By mandating a minimum MTU that is greater than the IP protocol minimum, are we assuming a fallback to TCP at application layer? I think the right thing to do for QUIC to stand on its own as a transport is proper PMTUD and be handle to min IPv4 MTU gracefully? Looking forward to the data about path MTUs.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Gorry Fairhurst
Sent: Wednesday, February 28, 2018 8:07 AM
To: Nick Banks <nibanks@microsoft.com>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; IETF QUIC WG <quic@ietf.org>; Eggert, Lars <lars@netapp.com>
Subject: Re: Space for Packet Metadata

For IPv6 that may be fine.

The QUIC transport paper (*) Section 7.1 speaks of "Packet Size
Consideration"- as far as I know this is just UDP traffic from google Chrome clients to google servers. They showed 3% unreachable for 1200 B payloads. Other networks could well be different.

We are in the midst of a large measurement campaign related to our work in TSVWG on path MTU discovery. I would expect a wide variety of Path MTUs - even though the current majority of paths will support 1280 bytes, many IPv4 paths do not - there are also many paths that support much more.

Gorry

*
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdelivery.acm.org%2F10.1145%2F3100000%2F3098842%2Fp183-Langley.pdf%3Fip%3D212.159.18.54%26id%3D3098842%26acc%3DOA%26key%3D4D4702B0C3E38B35%252E4D4702B0C3E38B35%252E4D4702B0C3E38B35%252E5945DC2EABF3343C%26__acm__%3D1519833743_fa365ff0c9cc6c6e266add2dba8f385f&data=04%7C01%7Cpravb%40microsoft.com%7C06b35440043a44c5741708d57ec55f30%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636554308540125446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=xUQP43CnIUkTU7lavv5i8GMNo5DK2Zkf9QbwhYo8SPY%3D&reserved=0

On 28/02/2018, 15:30, Nick Banks 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.'
>
> - 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

v2.23.0 | Report a Bug | By Email