IETF Logo Mail Archive

Re: Can I set the UDP checksum to zero when running QUIC?

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 13 March 2024 11:32 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 F3029C151068 for <quic@ietfa.amsl.com>; Wed, 13 Mar 2024 04:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVKGf6zViJ0g for <quic@ietfa.amsl.com>; Wed, 13 Mar 2024 04:32:14 -0700 (PDT)
Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on2122.outbound.protection.outlook.com [40.107.114.122]) (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 40676C14F748 for <quic@ietf.org>; Wed, 13 Mar 2024 04:32:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dP8AvZ68aWpG6maGO7ST0FPvkk3/jXsH7Q7mJWZ//ytldNKxWnwGpur3MFWKyoz+GPY/E+qo/pypngFo/1IUE1aRvnfy1bp4XOycdIB8/gxqLHPoOH4wQyO14OrShq2yIaqiEBxgTF+ZYXxBMj+E2fVrfr1++Dp0OxM6623kgKfoAl18Re7XXWuMZxaQ+GBj4Gzv5P7t71ca5H72Q1SvlCIA3cTg6y9BAxStt4QbtTUhxX/u1luvMKZuNbAH0a/k3M0rkAXFlER/x0VbVXIWM8n4j5PBRP3+kUwNGKOduFiJXygoAqsgHEKdPNuHhB93zfIWwFsxXYQI2OhGk0dn9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RKfSQmUQCu+Wo6+QTdM7PlkRkXdwmEboXba+xEqUgW4=; b=ObDw/f4jAC4TE+RGypyoqENhkBr7BTpBks3pzPkGdj2qhsdILAePuSQ287B/AETtjyEa+NM8FBFj0jcJ8GVmiSWmHySOZVTGpPUXkEBb1iey3nAgHXjixDSQHpNGn8ryJOvljWTX0EfpuAwKFauvMcRnSmHKp5CwJBQpw/Uaw20IFVcMwKjx90BN6wpX8GZN9lTsg3KSrMv3yLcLI3kCzflPQArUXApaPtRtSVUGfWoGimYw0FFJCATWAkZzfQxPDp29l/+RKfJRL5VGEOnu+Q3N/mDK6o1IRUXy0KnYvJZqD/LM+pWeobY6uNxfnSJPKY0MS9CFALKfEy/ThQmHdg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RKfSQmUQCu+Wo6+QTdM7PlkRkXdwmEboXba+xEqUgW4=; b=L4ibrHd+9gYPEwwrFK538ZQGGKIS86ScJ00WDbkRDj765hs50oIT8Fp7eEKR3Grmvg26CbNGgDf2iSEGkHKjykjogTR69uElGcnBJgj1cXJxxxb31R9xSOjQoxvGphIje9NnCdiRi58X/iMIDC+jShhfMp53vSZxkRNVeBhv8lM=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from OS7PR01MB11468.jpnprd01.prod.outlook.com (2603:1096:604:23c::10) by TYWPR01MB11286.jpnprd01.prod.outlook.com (2603:1096:400:3f2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.19; Wed, 13 Mar 2024 11:32:10 +0000
Received: from OS7PR01MB11468.jpnprd01.prod.outlook.com ([fe80::f30b:d19b:a355:b770]) by OS7PR01MB11468.jpnprd01.prod.outlook.com ([fe80::f30b:d19b:a355:b770%3]) with mapi id 15.20.7386.017; Wed, 13 Mar 2024 11:32:10 +0000
Message-ID: <a87e315f-1d3b-4ec3-aa90-87b7af30343f@it.aoyama.ac.jp>
Date: Wed, 13 Mar 2024 20:32:07 +0900
User-Agent: Mozilla Thunderbird
Subject: Re: Can I set the UDP checksum to zero when running QUIC?
Content-Language: en-US
To: "Shihang(Vincent)" <shihang9=40huawei.com@dmarc.ietf.org>, Christian Huitema <huitema@huitema.net>, Martin Thomson <mt@lowentropy.net>
Cc: "quic@ietf.org" <quic@ietf.org>
References: <6e69606a9d9443668dda4ee33bf8f825@huawei.com> <0522153e-2492-46b9-a2ce-e29a479e79aa@betaapp.fastmail.com> <b492b220-605c-4066-a245-5a3871a2e689@huitema.net> <b3d6ff62ae4048228826bd1010c45e3c@huawei.com>
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
In-Reply-To: <b3d6ff62ae4048228826bd1010c45e3c@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: TYCPR01CA0173.jpnprd01.prod.outlook.com (2603:1096:400:2b2::11) To OS7PR01MB11468.jpnprd01.prod.outlook.com (2603:1096:604:23c::10)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS7PR01MB11468:EE_|TYWPR01MB11286:EE_
X-MS-Office365-Filtering-Correlation-Id: a7aca753-2236-45b8-9e35-08dc435138e1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: cJ7YW6sqoA+YY3o2G9ykX/7EmYrC62pNnEgkj2wVtNVDTTqQYEzCtm/kVx+QSo6+lLMlfdTSxxVrFWUzLyWesn57Pk0+lpE4owj7p08cGYjT7r96WxdxK8hu2pRVkdEPAROHP6jGM0S5gSV+FqpBm5uDJHNQd915jV5uuSl3DlDTEdi04BRo6rbtiMTDPdnnFjoSfOFi+xMv1UlwfzmCdai9KV0hCoT0+gGEBWAtAxE2tNkmUE2C6b5OvA0FZ8hPMcjWWQ7DAvzWFTbtKrqf599AmXVduHOEd2bo3ZglpydhI4ATefFb4nugcd/2EPXWp8pNKBk8gT2tXyIJofWhPo8zYXCaeO1vR6JJvcfaYEvG/Efs1Wlq9q5iIt1UlZsqtWblNlQHJHJL7+Lg27quDmd26vyEzUbnj8fSPClODB1Dj3Ky6SM58rdkFPvMXw7B+WNKWIcs/mxRxR2UAO41ZFm3vIMTZEOArKAQpXerhm11PfC+EBaGia8KSEXq1kDpDzLRLVdOnBUzo6JnPMa6H4mXo++ZMfQFzRjxdeaUcLb1knCr1WQTV/j14NF5oq1fFcPYGACk+AVA0dUSy7fbS6ISK1rPg9hlQBlSHLV1jcg=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OS7PR01MB11468.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(376005)(41320700004); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: YbjJCox6qWXDmfgEJ/jzB554TRJrJF/7U8SuuM7W32l4bxmFJzKO08iE5f4jjfFrYY5G8SSTkQumdMrQNN6PIvGbLvSibkPexByuJBdkIvwGsR2B1jaPOF6TLOLwtLftHrBytSkY4WVAuKXNL5/Y5+LHDwzuu7sLTi2wGkJKSHNxpRRPrGznDyi7i0SSG93X/n62Y0TUguxmtlHeJhnDAmQBMvOuJ8BO8bn3aIVoI4ntqBMhgwiaSSHfkYCTQeOJ0mfgT5Qe12JgzjczIHlsg+cXv73NoI2bWCeBNgB5gZQqfGBJ/u4s8wY3dCpUxsoCd4E4f8byi4RFPDOpCNS/jaHfESYda79ESZGM//XbNTwx3T4vhCioJnTzvfSpq/gID1pw2qOQovjqorV2925+Tiepg0jMqtSFVHrAE1ta5OKqnnFcMKnPP8CsE/e1uoykkJXrp/TapKoraaDO7i5QQh6NRY3rYJh4EAHpYzxdxzpfQGrhVtGpAatvlEraZVObv2vCWu2XByD47QNkrSixaMp4dtfmUdiH/vM+EuCppYuQ8l/+cg4L+KBkmNg/EtKaPiExGsG2rsJGOGyzPJVUdqym4jqP63/a8aavSYCmUT4icwY8F3xVIM7KuftSUruUykkLQ6YVgufNc6N5A6s/5IQOF7w3Bk5kRz+78LaZt/TNs/DUtcsBSNQDwZTwH3iOfI5dJXHphqbibiKY+lVfU9a+EfUrHVggnyy710xzvY6WfYx4afOFzFoiqy5vF3+tQygX9c/+TgIjhphv818FKGSb/ByrsjOJYEXGm3iMvwmWiXYPKlf+dWNcU6+8YhcgITtJ1l89PjnuvNKgWqyFhZhHV7o81gyPKzoUlfLYAxsUdAM8b8F+BcBCXMKi6sMyAkoAgKl1Y6VL03SmlikKEeLluMb9YKWi2O1YsFDAwE/2K6yiGvlAOeKPpSRCXxU0Bmpfje6ENLLIoitqaj3Zynr/Yoh1eBj7kV3iVT1Qx1BJ/WjEzwfzGbF44yq9E4W9SMblnoun6O0tNWfQbjmFqMfie5sgvHhywmnYD/r133yyGWEFZpXKC/hn3HDANR7S9T5eOtkDURp2dO9qK1CpVwHIxnpAo2DTQcRARzd3cTnRnwSwueoM50cl9KAp2ujcf/N224bsiZNjLeBzPZ4BhlcS12HeJoUfTRR8DeUB80bldtMhpiTp59YsrhvI3VHF/Tk9VRXwfTSkO3e6tmOfpFb5SYf0T2hNpRSE/5o1Lf8OE8AXnjp0IBlvrEGcQbRGLh/o0yVC3+6GfCeUKJCd06fONGJ31EEq9/n2i4VjAe6hF0m8erquW+6ec/gYL/LZmOfwuPrfifi+Px1LqmIp2uYFOpk6TeQosOEwMIF/NDgFr8GixpijrTOU5yrB1Y4pN75BxeHozthkdIYJo6hSmwcq4d6MPmyZK70wqstt3mdXJrM5oXwhpICEhGlAdN5H0G4rxnDAAAogaMDIPgV0F1Hl3mLpoD88uNW1M83viYA2RCDB6hap52BBB8Ne5dwSYByQYUwtkmRaTKE8599Djmk7p4P1pkgfqgg43/kdiFgzO+I2HCXkIklHXw+tDJLQfztczNnXJGIpDFzj6pX0fQ==
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: a7aca753-2236-45b8-9e35-08dc435138e1
X-MS-Exchange-CrossTenant-AuthSource: OS7PR01MB11468.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2024 11:32:10.6386 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8MCAYXIYJG/CB+PVvWeh0gWgwGmxSVLo+bPN4aNlm1R86oTwNqtA36aGbowz8tSd5efFuxIFSBsEL7lE+Hqg2A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWPR01MB11286
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-HagV-RFx_0GOrvZDp88AY72yU0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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, 13 Mar 2024 11:32:18 -0000

Hi everybody,

I'm a complete outsider, but it seems to me that the effort to decide 
and remember where and when to use checksums and when not may quickly 
get bigger than the effort to just checksum everything.

Regards,   Martin.

On 2024-03-13 18:13, Shihang(Vincent) wrote:
> Hi Christian,
> The idea of trial is interesting. I wonder if the trial should be done per path or per end host? Are you assuming some middleboxes will mess up the NULL checksum UDP packets?
> 
> Thanks,
> Hang
> 
> -----Original Message-----
> From: QUIC <quic-bounces@ietf.org> On Behalf Of Christian Huitema
> Sent: Wednesday, March 13, 2024 12:51 PM
> To: Martin Thomson <mt@lowentropy.net>; quic@ietf.org
> Subject: Re: Can I set the UDP checksum to zero when running QUIC?
> 
> One the other hand, the cost of computing the checksum is tiny compared to the cost of encrypting the packets. So there is a small performance gain in not computing the checksum, compensate by the potential gain of loosing compatibility.
> 
> If I were to do that, I would do some trials. Until the handshake is complete, use the checksum. Then, send a trial packet with null checksum. If the peer acknowledges it, then further packets can be sent with null checksum. Redo the trial for each new path, or if there are large number of packet losses. Basically, treat that the same way we do PMTUD.
> 
> -- Christian Huitema
> 
> On 3/12/2024 3:57 PM, Martin Thomson wrote:
>> The question is more of a compatibility one than anything else.  What, if anything breaks if you do this?
>>
>> As noted, there are contexts in which not computing the checksum works.  So I guess the conclusion is that nothing breaks, so go ahead.  QUIC doesn't depend on the checksum.  All the cryptographic bits of QUIC use far stronger and more reliable mechanisms.
>>
>> On Tue, Mar 12, 2024, at 22:04, Shihang(Vincent) wrote:
>>> Hi QUIC wg,
>>> Since QUIC has strong encryption and integrity protection provided by
>>> TLS 1.3. I wonder if the UDP checksum can be disabled(using UDP Zero
>>> Checksum Mode https://www.rfc-editor.org/rfc/rfc6936 )to save the
>>> computation just like in VXLAN(RFC7348
>>> <https://datatracker.ietf.org/doc/html/rfc7348#autoid-12>).
>>>
>>> Thanks,
>>> Hang
>>

v2.23.0 | Report a Bug | By Email