Re: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 08 December 2023 19:01 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A749CC48EDDD for <ipv6@ietfa.amsl.com>; Fri, 8 Dec 2023 11:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (2048-bit key) header.d=boeing.com header.b="d1u+4cOX"; dkim=pass (1024-bit key) header.d=boeing.onmicrosoft.com header.b="SjYCRP06"
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 wVisz-KtJQTh for <ipv6@ietfa.amsl.com>; Fri, 8 Dec 2023 11:01:10 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 440D0C48EDDC for <ipv6@ietf.org>; Fri, 8 Dec 2023 11:01:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 3B8J14uA024501; Fri, 8 Dec 2023 14:01:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1702062069; bh=i34dlgWoKz/YVGWh3r48NSQxdcdY8s3UK3KnW50DQ1Q=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=d1u+4cOXf4pgEuopdwcdJaMR/ZQGTO4Kx9RM8U0nww3DhhygZ8+/1Rv8O9Q8QrjGK wxTQB6uTbpChwXaiHX7vbdSBfCWAvG7U+KILsTa9r6OCxM6LOGQXTWE0wINdFp3t3Y b6De/9CrbDTrAOpjH1+iY49sWo0/8UQMKXovKo5fe566/doIF0wS4sZHI6sNmMEkyX svDuQZBeCMPcrHaDJ0gxSO2Im7zH4LKX6mbtrhGGyOJ2AYiIOWbtV+ISvGVtTn0SAX lH3Ga+vg2wJHoE24UuHuM/mKxXscj+xmgWVuPFdflXSNsJz8V/EmGjfQ3CqNGeMrL2 opy41fxjrCcww==
Received: from XCH16-06-09.nos.boeing.com (xch16-06-09.nos.boeing.com [144.115.66.101]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 3B8J0voZ024112 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Dec 2023 14:00:57 -0500
Received: from XCH16-06-08.nos.boeing.com (144.115.66.98) by XCH16-06-09.nos.boeing.com (144.115.66.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Fri, 8 Dec 2023 11:00:55 -0800
Received: from XCH19-EDGE-C02.nos.boeing.com (130.76.144.198) by XCH16-06-08.nos.boeing.com (144.115.66.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34 via Frontend Transport; Fri, 8 Dec 2023 11:00:55 -0800
Received: from USG02-BN3-obe.outbound.protection.office365.us (23.103.199.145) by boeing.com (130.76.144.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.27; Fri, 8 Dec 2023 11:00:43 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=fFpTS9M45vLDIhbcSbNpeELsOlO+8eIpB4RoOK2T6nyQBrytclzlMmkfm/k41w8oK7rjLZbWznx2jfRlB6YYy1p2yEzVV/0+U2nRLEqLELCx14jodwdZnuwWBQZGiRatXLrrVlEEignn1K+LsMxcG9RDIW4NoqWbJ4q6btfXxhPTn/AcCiUixIohhaQxMpsMr1uSyuPdCz1smv5IWc9vDHlw/MjCzd1wIYS4yAc5Egvey6jTw+5W8ZxcSx9nIp7SkccGEPHisGq5/iHoRxLSqOSUk5GAKubPi88DbJG0pA7MJ73sJfONBQtVbAp/CqIEW1SHKHC1VtCpE5SKQjmDfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; 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=i34dlgWoKz/YVGWh3r48NSQxdcdY8s3UK3KnW50DQ1Q=; b=i6KHB8SP0emCv/Ku3sIneVnry1D0+P+11K648qTdP6vA4CMFHV8rGEZb3u2vg+CBXWeQ1kULSTeFE1D66h52VYD04BQp4PDnfwneVwS3XRAIXgTT/xCvCvCV66gp/sX6zZ2J7g/5TsnTG2gsVucy/xNuWpFIVCwCswL/9lNJqBGFKyPQqYhgv0hMJSxokFCfd+Jmgk+7iBV14RMuLYOXc8jD96v1l4SNs3kBCb418r6wJ0N818/CV+Dftslj0dBgF0BWQvsxY+G+BTw8LSasloES81mS70mZWPm5WOFDA6dp5mAMzfL9/7MhVKO70HYtJU9aneM8Y7GYW1LIsu29qA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=boeing.com; dmarc=pass action=none header.from=boeing.com; dkim=pass header.d=boeing.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.onmicrosoft.com; s=selector1-boeing-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i34dlgWoKz/YVGWh3r48NSQxdcdY8s3UK3KnW50DQ1Q=; b=SjYCRP06w3yRkWeqQ0fZuXpuxs8RtuHHZjpglthxlOE70KLUJMWPxg6LDNfrsMlB/KyCMYDutOks8pmn7WpoAXJMs5S0bRZThLIk4kwcfujEtSDXj8JGXE7FEQk66Ap2bI4F5jSp8cqpr+PQ5xt6kPda3NhEuTUTxFYbn2S0Fnk=
Received: from BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:183::19) by BN0P110MB0949.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:16d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.40; Fri, 8 Dec 2023 19:00:42 +0000
Received: from BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM ([fe80::5df2:a8d0:34f2:c244]) by BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM ([fe80::5df2:a8d0:34f2:c244%5]) with mapi id 15.20.7002.040; Fri, 8 Dec 2023 19:00:42 +0000
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Tom Herbert <tom@herbertland.com>
CC: Christian Huitema <huitema@huitema.net>, IPv6 List <ipv6@ietf.org>
Thread-Topic: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt
Thread-Index: AQHaKgjXfsafvBNVFUScy85NfWCadQ==
Date: Fri, 08 Dec 2023 19:00:42 +0000
Message-ID: <BN0P110MB1420BABB15276F252600F998A38AA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM>
References: <13091d25c5874d5ba27b2de77d337646@boeing.com> <CALx6S371iasRTW+gzjgCPT1BY-KxZZau2Fu3qGYnoHpiu3o9tQ@mail.gmail.com> <BN0P110MB14205F118B67DD0225A18634A38BA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM> <CALx6S36TZqh9h4aZ-o5gkY5Hp1Md2w5gPwpyO4weWeVwqXC5yQ@mail.gmail.com> <c0d3f33b-1193-470a-9f72-2c39dcbacb4f@huitema.net> <BN0P110MB1420A66D481B00EF33487E36A38AA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM> <CALx6S36KyazyS3d6GkkvTJr=s9SnA7WT_RJpEztLjmnrQNMrRQ@mail.gmail.com>
In-Reply-To: <CALx6S36KyazyS3d6GkkvTJr=s9SnA7WT_RJpEztLjmnrQNMrRQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=boeing.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB1420:EE_|BN0P110MB0949:EE_
x-ms-office365-filtering-correlation-id: 9f4e6e5f-a6e6-4457-c232-08dbf81ffa28
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UaehXR9pxssxXjqBuchQEvlZhhuq/LrA1k3xAmxanTKwx2Nd+RghtNsCaCqKhKrU0RGwxDMc3YdvVbpxdLNIygqQ7A3M36CqA0Hh2K0ekLk6yCU4PTSbuZUNpPgNQOHqBCiO6yScVkdafvmdO9wl06dM+LYTPEFm9YeQETEtZmPRTynMLz+BknOfFfFo2R0TVoIR0URFOAzKMddBxuWeEeH3Uie+gwYUJZbNi5yQoBi53wjZit8zxrvbdjzzdr5YE6tYxBASuvHi9zatNNvbDqU1Lbmne3uKcXpgPIfmVLQ+zFgXCnwAeS0XTNu2uqgiEwfDbLgXRC5FsUEbMj3pTfv5NjJou6jN3k+iG2B/+ENUGfFqDZms2s99/w88zLELNI9yddEIkCl1FRdXldG0Pi3FW3a61Npif6OqXz8z63XlCDB3Z0IhD8xDacWqNaduKOriSiHywa8bx96759buwOPrOjIF+FHWKud3wFr62UP5FBYFXQJOgio23BpG1ROhD13SlAAGt1AaMcEfS/JaKVU7fk/2WgNnE0QcFGM2Gizx5v4PMoattPUqsw7RioA8pmtR5HN+/heJTs6dEcxdsBbJXxXXKT3TgFKa2B1w16M=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(366004)(230922051799003)(186009)(1800799012)(451199024)(66899024)(76116006)(4326008)(54906003)(6916009)(64756008)(8936002)(66946007)(66476007)(8676002)(66446008)(52536014)(66556008)(966005)(498600001)(7696005)(71200400001)(86362001)(5660300002)(55236004)(33656002)(38100700002)(2906002)(30864003)(53546011)(66574015)(26005)(9686003)(122000001)(83380400001)(6506007)(38070700009)(55016003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Cc6YJ7sicLAnpFXACODnBFUyPM2pDWT64QrrUgcte9TYUVhXKKaXqkwSR9bo6XWSWnz8kh3RYzyKEHcF5CxKdmxsezAf0f7Kt1MSIG2mNVhqt7IP71wHXo+AuEPKNmEiN4xbKLbwwhTXNVygbmxpEUANd8Aud/CTBU2AT547EO1mcNA3REUdrLtPYg0ysQY2RHWa3SDCslbzSZUm3SnuBf7DXM6CXL//vnumMpe/fzWpfRxw/xpWU1NRFzudWopOMV5Z3BS6iAdjm31/w6iDbAxW8Wu+zuiGTFl2MdN5z/Se6Qq1tE4G4KQEUovUEqbitTQfrZ0HqY9VXKRhH17qor8HbrU5UKsKiGWi+OoLrktt+qnSsF1VY2ILXElnlyBkoVS/r44vNqDXdsBiPs1Vn2+BFpPIQ8nV/DdpKgdeHZRikh4vTYu92no9AhOZE2bgc5+q85JjM8ZNbMnzwAlbC5h1ZTD4B9Jr0gkJWu1rjwuJQac9lA495FsHrf6cINC8ivgE/F4SRmj4sP2GEiMdvv/N5xYFVX9VT2nVx42OfrBcGz0j5pYOEHtfDfu5Zi9czhfhtIB5jwdWDPuNhm3hzBiOuxdqPnsjeW2DC66OJ+0PN6OqNRTLhsLugebvzAfNmJRbeEVdM/OkQDwmLoxwLmAB2Gq059DEcUUCuwnC8QkqL/E8Zx3Gg/BZ2IjR8dyAqJj1HGbeJdUu3BME2loHhfgf2kx6lzkvlMWzEu15leovMqaD1L7tQiubzkbdrYOra9CYLng4OHV7ZnGga3KyVFHFpdNPht5DWuce+Pv50WjTXAvK6y/C5B7A3ax7BzzRA2hon59WlzK+7lapiTs9cBWmyAbCWGuiA/+ZRN9HB8rgashW6lhyDVyAV2+NMowW+tD5AxELQkT9xWi+pIda92J3HM7NLAMGaFxjyeWcwm928n32D7+c5D6jCUaMc2RiyncCvFxYYEKG2XV2XhIIoGAKwhtYRHCgrfA1ZTL5H2wylYSCpgfDNZgptuvkjtDhWXBuLvu5MO05QbiBSg64aMZ6QGUm6YLa9on7GpFJHiKc03nwj+KNW2ufB4BWDoMx7iFnaxVmjwXfa2coInv71RPJ7HEpYOAS0oANdihise6NCZCzl8srhjgMt/k3le8j88YZw5nm3DZL2pY6bWacvQgK6e22cXP+RRe0Tbt9SNnCrrez9ggX81Nfjq16zYnTp1ZpRdOF8vEtDhZRswM1tSxOZoqEGcepAzyEg4r1GOgZHPOQ4sk/eHuG7lqJgjEsmP99wwhzGjb50q5HScYimKBZYrzFq2QHkoJReGHTDPgzxAo2EOMyMaKgYFggIhVQ478NUhoysRQK3ZIf2QboGPExvR9PgViDiMSsB/Z4x5xsfMGRXk+72hhT74yTSi5THHRvd4GvdxpGPNRyl2yub23MaPYlO6Jv85Q93F52gZ0xrWmHYEO8rPlPURD5goQskO0HVrsko5AAsXkybFd/kivpuvgRbwRr/LvNV50OOjf9AnLYyd++mpctAf6Lgymb
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f4e6e5f-a6e6-4457-c232-08dbf81ffa28
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2023 19:00:42.7548 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bcf48bba-4d6f-4dee-a0d2-7df59cc36629
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB0949
X-OriginatorOrg: boeing.com
X-TM-SNTS-SMTP: DBE1FD2631AEAF7D015EF1D31EAC1B0E0F3C7F2A3FCA264C48E10AD311609D822000:8
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UhYTYka6Xu9E19GRC_Q-kguoATs>
Subject: Re: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Dec 2023 19:01:14 -0000

Tom, the service backs off during periods of congestive loss and can resume a more
aggressive profile when congestion subsides - the service is therefore adaptive. And,
the service is verified to improve performance for TCP and generic UDP as shown in
the iperf3 graphs in my Intarea charts. In fact, TCP does best of all.

Thank you - Fred

> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Friday, December 08, 2023 9:12 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Christian Huitema <huitema@huitema.net>; IPv6 List <ipv6@ietf.org>
> Subject: Re: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt
> 
> On Fri, Dec 8, 2023 at 7:37 AM Templin (US), Fred L
> <Fred.L.Templin@boeing.com> wrote:
> >
> > Christian, I am working with the DTN LTP over UDP transport, and what I have found is
> > the performance is increased only by increasing the segment size even if that size exceeds
> > the path MTU. I have shown performance increases with segment sizes all the way up to
> > 64KB even over 1500B path MTUs, and I believe that still larger segment sizes (over paths
> > with sufficient MTUs) would do even better. This was also a well-known characteristic of
> > NFS over UDP back in the early days, and I believe we will find other transports today that
> > would benefit from larger packets.
> >
> > I have tried many ways to apply the "conventional wisdom" you have expressed to LTP/UDP
> > but have seen no appreciable performance increases using those methods. I tried using
> > sendmmsg()/recvmmsg() and they did nothing to improve performance. I then implemented
> > GSO/GRO and again the performance increase if any was minimal. I even implemented a
> > first pass at IP parcels and sent 64KB parcels with ~1500B segments over an OMNI interface
> > and that did give some minor performance increase due to the reduction in header
> > overhead but nothing within the realm of simply sending larger packets where the
> > performance increases were multiplicative.
> >
> > I object to categorizing this as a transport issue - this is an Internetworking issue where
> > large packet sizes currently are not well supported especially when they exceed the path
> > MTU. I believe many transports will benefit from using larger packets, and that a robust
> > fragmentation and reassembly service is essential for performance maximization in the
> > Internet, and my drafts clearly explain why that is so.
> 
> Fred,
> 
> For transport protocols dealing with segments the interaction with
> fragmentation can't be ignored. Consider if there is a 1% packet loss
> in a path for a flow. If one segment equals one path MTU (no
> fragmentation), then 1% of segments are dropped, If one segment equals
> two MTUs with fragmentation then 2% of the segments are dropped, if
> one segment equals four MTUs then 4% are dropped, If one segment
> equals 32 MTUs then 32% of segments are dropped. Dropped segments need
> to be retransmitted and those retransmitted segments are subject to
> packet loss also so the goodput for the connection can quickly drop
> off a cliff when using fragmentation. As I mentioned this is
> exacerbated by the fact that the fragments themselves can be the
> source of congestion causing packet loss in the network.
> 
> I think your argument that fragmentation is essential to the Internet
> would be stronger if you can show why packet loss isn't a big problem
> for transport protocols that use segments as the unit of congestion
> control and retransmission. Also, your focus for analysis seems to be
> on LTP, but if you want to make a general argument that fragmentation
> is essential for the whole Internet I suggest showing how TCP and QUIC
> behave when their segments are fragmented with varying amounts of
> packet loss in the path.
> 
> Tom
> 
> 
> 
> 
> 
> >
> > Fred
> >
> > > -----Original Message-----
> > > From: Christian Huitema <huitema@huitema.net>
> > > Sent: Thursday, December 07, 2023 3:59 PM
> > > To: Tom Herbert <tom@herbertland.com>; Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > Cc: IPv6 List <ipv6@ietf.org>
> > > Subject: Re: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt
> > >
> > > On 12/7/2023 11:51 AM, Tom Herbert wrote:
> > > > On Thu, Dec 7, 2023 at 7:58 AM Templin (US), Fred L
> > > > <Fred.L.Templin=40boeing.com@dmarc.ietf.org>  wrote:
> > > >> Tom, to the point on performance:
> > > >>
> > > >>> Please provide references to these studies. Also, note IP
> > > >>> fragmentation is only one possibility, PMTUD and transport layer
> > > >>> segmentation is another and that latter seems more prevalent.
> > > >> If by transport layer segmentation you mean GSO/GRO, it is not the same thing
> > > >> as IP fragmentation at all. GSO/GRO provide a means for the application of the
> > > >> source to transfer a block of data containing multiple MTU- or smaller-sized
> > > >> segments to the kernel in a single system call, then the kernel breaks the
> > > >> segments out into individual packets that are all no larger than the path MTU
> > > >> and sends them to the destination. The destination kernel then gathers them
> > > >> up and posts them to the local application in a reassembled buffer possibly
> > > >> as large as that used by the original source. But, if some packets are lost,
> > > >> the destination kernel instead sends up what it has gathered so far which
> > > >> may be less than the block used by the original source.
> > > >>
> > > >> IP fragmentation is very different and operates on a single large transport
> > > >> layer segment instead of multiple smaller ones. And, the studies I am referring
> > > >> to show that performance was most positively affected by increasing the
> > > >> segment size even to larger than the path MTU. I implemented GSO/GRO
> > > >> in the ion-dtn LTP/UDP implementation and noted that the performance
> > > >> increase I saw was very minor and related to more efficient packaging
> > > >> and not a system call bottleneck. Conversely, when I increased the segment
> > > >> sizes to larger than the path MTU and intentionally invoked IP fragmentation
> > > >> the performance increase was dramatic. You can see this in the charts I
> > > >> showed at IETF118 intarea here:
> > > >>
> > > >> https://datatracker.ietf.org/meeting/118/materials/slides-118-intarea-identification-extension-for-the-internet-protocol-00
> > >
> > > I don't doubt your experience, but this is not what we saw with QUIC. In
> > > the early stages of QUIC development, the performance were gated by the
> > > cost of the UDP socket API. I have benchmarks showing that sendmsg was
> > > accounting for 70 to 80% of CPU on sender side. Using GSO was key to
> > > lowering that, with one single call to sendmsg for 64K worth of data.
> > >
> > >
> > > >> Again, GSO/GRO address performance limitations of the application/kernel
> > > >> system call interface which seems to have a positive performance effect for
> > > >> some applications. But, IP fragmentation addresses a performance limitation
> > > >> of transport layer protocols in allowing the transport protocol to use larger
> > > >> segment sizes and therefore have fewer segments to deal with.
> > >
> > > At the cost of very inefficient error correction, repeating 64K bytes if
> > > 1500 bytes are lost. The processing cost of retransmissions with
> > > selective acknowledgement is not large, it hardly shows in the flame
> > > graphs. Also, the next more important cost after sendmsg/recvmsg is the
> > > cost of encryption. If the application had to resend 64KB, it also has
> > > to encrypt 64KB again, and that costs more than re-encrypting 1500B.
> > > Given that, I am not sure that for QUIC we would see a lower CPU by
> > > delegating fragmentation to the IP stack.
> > >
> > > That does not mean that larger packets would not result in lower CPU
> > > load. It would, but only if the larger packet size did not involve
> > > fragmentation, reassembly, and the overhead caused by the occasional
> > > loss of a fragment.
> > >
> > > > Hi Fred,
> > > >
> > > > Fewer segments, but NOT fewer packets. The net amount of work in the
> > > > system is unchanged when sending larger segments instead of smaller so
> > > > there won't be any material performance differences other than maybe
> > > > implementation effects at the host and no effect at routers. Segments
> > > > are the unit of congestion management and retransmission in a
> > > > transport protocol, but fragments are transparent to the transport
> > > > protocol-- this distinction can cause material issues in performance.
> > > >
> > > > It's pretty easy to see why this is. Consider that the minimum number
> > > > of segments for a connection would be to use 64K segments and fragment
> > > > them. For a 1500 MTU one segment then would be sent in 43 fragments.
> > > > The problem is that if just one fragment is dropped in a segment then
> > > > the whole segment is retransmitted. Furthermore, the fragments
> > > > themselves are likely to be the cause of the congestion at routers. So
> > > > there is a high likelihood of creating congestion in the network and
> > > > needing a lot of retransmissions. Even if CWND goes to one, each
> > > > connection can still send 43 packets and SACKs don't help because
> > > > there's no granularity at 64K segments so congestion control really
> > > > wouldn't be effective. The net effect is likely to be very poor TCP
> > > > performance.
> > >
> > > Yes. That's actually a known issue with GSO, and why GSO is typically
> > > limited to no more than 64K. If the sender does not implement some form
> > > of pacing, the segments will be sent back to back, causing short peaks
> > > of traffic that can cause queues to fill up and overflow. But it is
> > > difficult to delegate this pacing to the kernel, because the API only
> > > expresses the pacing in "milliseconds between packets". Segmentation in
> > > the kernel or the drivers would have the same issues.
> > >
> > > > While I think there might be some incidental positive performance
> > > > effects in host implementation by using fragmentation, I really don't
> > > > see how it addresses any fundamental performance limitation in a
> > > > transport layer protocol like TCP. In fact, I don't see how IP
> > > > fragmentation could possibly be better than doing PMTUD with SACKs
> > > > especially on the Internet.
> > >
> > > Yet another issue is that Fred is not the only one with that particular
> > > bad idea. The UDP options defined in TSVWG include a
> > > sgementation/fragmentation option that looks very similar. The two bad
> > > ideas would probably have to be reconciled in a single bad idea.
> > >
> > > In any case, Fred is making arguments related to transport, which means
> > > this draft ought to be discussed in TSVWG.
> > >
> > > -- Christian Huitema
> > >
> > >
> > >
> >