IETF Logo Mail Archive

Re: [Int-area] IP parcels

Tom Herbert <tom@herbertland.com> Thu, 27 January 2022 22:46 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 620603A082F for <int-area@ietfa.amsl.com>; Thu, 27 Jan 2022 14:46:49 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yw7wRDUt9o1 for <int-area@ietfa.amsl.com>; Thu, 27 Jan 2022 14:46:44 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26C43A0829 for <int-area@ietf.org>; Thu, 27 Jan 2022 14:46:44 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id m11so5832889edi.13 for <int-area@ietf.org>; Thu, 27 Jan 2022 14:46:44 -0800 (PST)
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:content-transfer-encoding; bh=cWMdpJM+3s/efr8qUjt0PuyhNCHax04EHqEjthlys00=; b=fDzgndQVRR6CVkmqzHXI02RMnah2Up9ZkriXALOqwplDZ4ZB/U3N4ug8p+LTpzqMGC 9tFMD5wUPaGzj87rV3kWYBkem3VXGw5BGZdzh5c8t8XhrarzW2Dkpj95cFeu8KvnJwJ0 GV6wWEIlVm3CiU+7lGEOjeDDsJcx/658tmO9KnGUkMk1eM3aKP4XxOi87ROaan4LXeVR e3KFhSIPuDIm60JPrsbH5D9VWuHhDDNxvvvK6DkyWHQ+S9lDuAkDv0dAvYpUx0vEIeIN h3GvOtm5FKbP4+hEZIjGFa2lfuPNDR29NX2m6MMMSZ8C1L7Ka10DkYaF8aoLK0uGfXZK Hafw==
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:content-transfer-encoding; bh=cWMdpJM+3s/efr8qUjt0PuyhNCHax04EHqEjthlys00=; b=WU2z3G11fK/FMYXh2Ma9X15Egiqb6mFbJaXGGhIQopff/f9uh7fgcnFn7WbTpsLU0d cFC4nPYhu0Jv9E8KLEPEvBRmw4DuQ8Y1mq9mIwAReWGmhE6NZ32cwyCmoxGY8Tb3CUkJ QsxKeJPb085d9tmrynHrRRZRLikH//bxgnULeQVk+AqF2j4ZIkmt0cTEfTQWKASDgytC O90vfUdvXs3piYtk8u3GBDSI8rMvGbPB3BeGF/4N18trrnBDDlODKrS3Fst3B158NmHW o+Mp6cDZwscQ7xoBoxj+9Ql4BQZqCZYxrvh+Jkb0XlbBlrSW420hpkjdowVkxKQk2dyG CX6w==
X-Gm-Message-State: AOAM530xBimnBjSTItirbRECN5DGFw0DDlB7XTE60BOo0RVAyqdGclEJ c5/+9Ql3YBdRriZ+61AVoSQkIB3Zo80MyYeOSrb1e5BetSWbXg==
X-Google-Smtp-Source: ABdhPJxjqyLIoQbIBkV7LffY1OsxT0lQ77W6ZaVRLNxv7aZAsjPaYnlzWxufHFN29UpmQkMQRSGFsFekRM/lPEwYjhA=
X-Received: by 2002:a05:6402:358e:: with SMTP id y14mr5583007edc.136.1643323602111; Thu, 27 Jan 2022 14:46:42 -0800 (PST)
MIME-Version: 1.0
References: <d6c6fec034a74e319cc9840ecb0f5603@boeing.com> <7cf11719-20f4-26ed-f332-18633c65491e@huitema.net> <CAC8QAcc6vHjAk50MtNLFOKaFQuV-1e_L2U_-O4AX5bJW9=JUTQ@mail.gmail.com> <691268A6-4609-4D94-87CE-7B4436B9982F@strayalpha.com>
In-Reply-To: <691268A6-4609-4D94-87CE-7B4436B9982F@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 27 Jan 2022 14:46:31 -0800
Message-ID: <CALx6S37gZV6XoGa=CJ+jzqdeQU0nuGe4y3f=-v4kF6GuQh3veg@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: sarikaya@ieee.org, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/-L_yEpLHfVZoguaGLh0xW3svQJs>
Subject: Re: [Int-area] IP parcels
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 27 Jan 2022 22:46:49 -0000

On Thu, Jan 27, 2022 at 2:17 PM touch@strayalpha.com
<touch@strayalpha.com> wrote:
>
> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. the current ones to extend option space after the SYN (draft-ietf-tcpm-tcp-edo).

GRO and GSO are software implementations and in most deployments
>
> Although I appreciate their zeal for optimization, implementers of GRO/GSO still need to play by the rules of TCP and UDP. It’s not clear they are (e.g., coalescing packets with different unknown options), and when they don’t, I want to be clear that it is they that are the problem.
>
Joe,

GRO and GSO are software implementations in kernel networking stacks
and in most cases these are open source projects of Linux or FreeBSD.
If they have flaws or there's areas for improvement, then by all means
submit patches to the respective project-- that, after all, is the
whole premise of an open source project. The hardware cognates, TSO
and LRO, do tend to be more closed and for this reason they haven't
gotten much traction-- TSO has seen a some amount of deployment, but
LRO hasn't because of the problems of putting fairly complex
algorithms in hardware. That problem is addressed once we have
sufficiently programmable hardware so the stack can program things
like GSO and GRO in hardware as easily in hardware and of course this
should be done in ubiquitous open source that works across all
hardware vendors.

Tom

> I agree that the common Unix socket interface has performance flaws, but perhaps it’s that interface that needs to evolve.
>
> Joe
>
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Jan 27, 2022, at 1:29 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
>
> Hi Folks,
>
> Thanks Christian for explaining how GSO/GRO are used by Quic implementations. So the use is not mandated in Quic RFCs but rather used in implementations.
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

v2.23.0 | Report a Bug | By Email