Re: [Int-area] [EXTERNAL] Re: Call for WG adoption of draft-templin-intarea-parcels-10

Tom Herbert <tom@herbertland.com> Tue, 12 July 2022 14:47 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA16C14F749 for <int-area@ietfa.amsl.com>; Tue, 12 Jul 2022 07:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.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 gVf7uiKPDl3g for <int-area@ietfa.amsl.com>; Tue, 12 Jul 2022 07:47:48 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F675C14F73A for <int-area@ietf.org>; Tue, 12 Jul 2022 07:47:48 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id c15so10197932ljr.0 for <int-area@ietf.org>; Tue, 12 Jul 2022 07:47:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTYkYuUEf7lYhx476/MwhgoD8OdfYVJaQNlrbsg1I2g=; b=dwtMm5k3N/jZELDdSBg80GRQRhhahaye5S8eGbDSrXle28f5Qvy8uac35Fti71Upn0 V8pQy8CKq4UCzyA1wWls3sULFs9vYyhKDR1nLrDyFCKyWZuvzrpYUeslcATO7ln9ZE7b /hAko6Ck5xTNWvTS4/nKMji7QvLqwckK/OVBg6kdZeTUPc2W4IPivzVjrx45Mah55TKK f/dkvRMJHevS2F4IZDx6WJHPAZkrAXaF78avY6++qZk5AMFBfbzggPXqwl2mnhR8mJDN KbB0a5X6f3HlTRp34koJKQ+iarAel6GFrc1mmgadSn+kBGAjlrAGmM3jEK2lFGhomAoW diMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UTYkYuUEf7lYhx476/MwhgoD8OdfYVJaQNlrbsg1I2g=; b=u5tyizUoABNq7u6P8901jYI/zyG69A3yoYE7SeFD1jhOV+tfFZdZ1O11ndfQdNXcsd rH1l8BXgMkluud3nEKsE8SkPDA1eF82jmv5y2Kwmkx8Vk1FsCQykY9rMOORt8Utzoeyw 5GhCxAda13ENw4giNMf+7gZ/IGSKNp2troSDNSIpTmwTQ0B9S7L1p+vv6HYxPypDWxej +CGdOxZFyd5gLDwO4D2JpTPpSuVJJvALjz9yHt2ESg8AfvA8HHpkZytmMaUsCVXQgleV DlV1idjCtNZ/HwLblg8yO/UzcGiU1FbKB9OF23PFfwf0GevXF+NnlMYTGSDD+EY4BXmD AcnQ==
X-Gm-Message-State: AJIora8VoaulMzfJCsgf/aLRbb6FiSjz6nnzutfQ3O9qJzWij+T3bF8s kJgFag/EiYY5rXEbBODVChhD/Qxfv6gDAAPbDJvS5x9/Ni8=
X-Google-Smtp-Source: AGRyM1umzkWvPyxS8PYkNScBcVgLyQbL1QoEUZMMI4hZ1Rd5Z1YnWdALCuKiRMuneosHrooyv9j4hFBzn1cZYsmnaRg=
X-Received: by 2002:a05:651c:1601:b0:25d:744b:cdb5 with SMTP id f1-20020a05651c160100b0025d744bcdb5mr4052638ljq.351.1657637266433; Tue, 12 Jul 2022 07:47:46 -0700 (PDT)
MIME-Version: 1.0
References: <SJ0PR11MB57692D589B130307F4C9C823D1B29@SJ0PR11MB5769.namprd11.prod.outlook.com> <BYAPR13MB2279C0291E3AC5998958824D87BD9@BYAPR13MB2279.namprd13.prod.outlook.com> <f90f462f9df94e2a82a1b8afe598a204@boeing.com> <CALx6S35Ute7f3D_zdbxauBiR+KG7J5gqSwXhH+MQcfQGuHGHzQ@mail.gmail.com> <5dcb3714b5da4d9bbfc4fe0e7545bd87@boeing.com> <CALx6S36Rf4KuT-DSgd8wi38rVzG8qvDH+LOqjBP4UKzK=V=+VA@mail.gmail.com> <ac0fda9746514e4ab8d99b3d6824bf38@boeing.com> <BN6PR08MB2803E6BAF9E5537ECF3DA401E6869@BN6PR08MB2803.namprd08.prod.outlook.com>
In-Reply-To: <BN6PR08MB2803E6BAF9E5537ECF3DA401E6869@BN6PR08MB2803.namprd08.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 12 Jul 2022 07:47:35 -0700
Message-ID: <CALx6S36hGhH4UvGpoGShyFh_F-6z8tZrDvH-OSVK4ZD3jogM+g@mail.gmail.com>
To: "Robinson, Herbie" <Herbie.Robinson@stratus.com>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006ec76f05e39cc084"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/YCggnIQmuA1I5BM913FMITNa0eg>
Subject: Re: [Int-area] [EXTERNAL] Re: Call for WG adoption of draft-templin-intarea-parcels-10
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 14:47:49 -0000

On Tue, Jul 12, 2022 at 7:31 AM Robinson, Herbie <
Herbie.Robinson@stratus.com> wrote:

> Fred Templin Wrote:
>
> > Tom:
>
> >>The algorithm isn't the problem, it's supporting new protocols and
> multiple
>
> >>checksums in a packet in hardware.
>
>
>
> >But Tom, how hard can this be? Instead of running the Internet checksum 1
> time
>
> >over N octets of data simply run it M times over N/M octet chunks of the
> data in
>
> >succession but still in a single pass. You spoke before of NICs adapting
> to support
>
> >TCP jumbograms – if they can do that, why not a very straightforward
> application
>
> >of Internet checksum? I haven’t looked at this in a long while, but isn’t
> this also
>
> >similar to what UDP-lite did?
>
>
>
> The various hardware adapters that I am familiar with (most of Intel’s
> high end line) use a fixed sized ring buffer with a fixed sized slot for
> each packet received.  They are already restricting the use of all features
> at the same time because they don’t have enough bits in the per packet
> slot.  They certainly have no way to deal with reporting success or failure
> of an unbounded number of checksum computations in a fixed sized slot.
>

Herbie,

Generating multiple checksum is required for TSO and some devices implement
a generic mechanism that might be extended to work with IP parcels.

On the RX side, efficiently handling multiple checksums in a single packet
that cover large non-overlapping portions of the packet is difficult. This
can be solved if the IP parcels header has a checksum covering the whole
packet so that the receiving host doesn't have to verify the checksum of
each segment. But, you'd still want the checksum in each segment in that
case.

Tom