Re: [tsvwg] a new method of congestion control

"touch@strayalpha.com" <touch@strayalpha.com> Mon, 05 June 2023 14:42 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A165C1522A4 for <tsvwg@ietfa.amsl.com>; Mon, 5 Jun 2023 07:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level:
X-Spam-Status: No, score=-1.316 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 yQol_glyzy7U for <tsvwg@ietfa.amsl.com>; Mon, 5 Jun 2023 07:42:14 -0700 (PDT)
Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (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 E49DCC151B2B for <tsvwg@ietf.org>; Mon, 5 Jun 2023 07:42:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ENTbeGnaKcojXmd2kRPXrN4enAwolzmqtg/km1kvmOU=; b=NXxBQ2NSYbjsnSDMogkbr4sRr6 zVW6pI2Txq0Ht3hq1cVJqP3W1yoy1JgoJAbrtLnOhTr7XcAzvqT8FUrRwvkFSS4V8BXJ1xjRi0B6u p0AMQBzRS/8MfxvLJ/tfBiegu/87Rrk8qqEtNie29vY9BFbxqCcrKn5NDEwxdtH+Gt4GuFOtIs2YU hYadoTfYh/GJx4I8MO+fHGnDI5QKRfctEf7Xy6jK8EPD7ZDmXb5Xzvz0l6Bj9ngfv8SLDciLxrWez ixmWB1Qw2gJ9R5GwutFZsg/+an79JyoTfQL0leb0PbquUc3YmFH+7jYSnmGUuRZ7Vp1zGTuPx0xNG pnGBhoeQ==;
Received: from [172.58.208.6] (port=8346 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1q6BPM-00BlZN-Ck; Mon, 05 Jun 2023 10:42:12 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <0EB4FCC9-99F3-4E29-BB12-22B2DAC9AB95@earthlink.net>
Date: Mon, 05 Jun 2023 07:41:56 -0700
Cc: Dave Taht <dave.taht@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF196E1C-DBD9-4148-83F4-3C81D8324F47@strayalpha.com>
References: <CAA93jw6TJEciW8QhgbSe=0ZTk6njhpxMTQ3ETxzy73hhcP0yAw@mail.gmail.com> <C21F06B7-79DE-4726-9DD7-D91BF9DB9AC5@earthlink.net> <16922F7E-EED2-4298-98EC-AA7784A0D4AD@strayalpha.com> <0EB4FCC9-99F3-4E29-BB12-22B2DAC9AB95@earthlink.net>
To: Mitchell Erblich <erblichs@earthlink.net>
X-Mailer: Apple Mail (2.3731.600.7)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ncSpgt0XMl42jTI-UBWEQUMrSu0>
Subject: Re: [tsvwg] a new method of congestion control
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jun 2023 14:42:19 -0000

On Jun 4, 2023, at 9:14 PM, Mitchell Erblich <erblichs@earthlink.net> wrote:
> 
> Joe,
> 
> 	One would need to duplicate Appropriate Byte Counting (ABC) by Allman / Pacing in Ethernet, but why would you want to when you already had it within a experimental CA in TCP?
> 
> 	If you flood packets and a intermediate system (router) did a tail-drop or a random-early drop, you still drop packets.
> 
> 	If you have out-of-orderness that jumps because… then you drop packets
> 
> 	If you fragment and drop a fraction of the packet you drop…
> 	
> 	If you re-route because of the change of the routing table and you re-order, you drop,,,,

However, if you reserve resources along a path and don’t change paths, then you don’t drop and none of the above applies.

That won’t work in a heterogenous arbitrary Internet, but can in a highly controlled environment - especially when tuned for a specific workload.

> 	...
> 
> 	Why create a wheel when it already exists???

My reply wasn’t suggesting we should. But even in the IETF, we do.

Joe

> Group,,, Sorry, about the verbose response….
> 
> Mitchell Erblich
> erblichs@earthlink.net
> 
> 
> 
>> On Jun 4, 2023, at 8:15 PM, touch@strayalpha.com wrote:
>> 
>> Ethernet has a LOT of extensions:
>> 
>> IEEE 802.1
>> en.wikipedia.org
>> <wikipedia.png>
>> 
>> Could this either be some subset of newer extensions or revival/vendor-specific variants of past attempts?
>> 
>> Joe
>> 
>> —
>> Dr. Joe Touch, temporal epistemologist
>> www.strayalpha.com
>> 
>>> On Jun 4, 2023, at 7:50 PM, Mitchell Erblich <erblichs@earthlink.net> wrote:
>>> 
>>> Weird, In my Opinion (IMO),
>>> 
>>> 	How do you separate out AI versus non-AI flows, so you can tailer one type network flow to AI aware applications?
>>> 
>>> 	Is AI consuming even 20% of network bandwidth at this time?
>>> 
>>> 	Isn’t Apple’s ?Siri? an AI application approaching 10 years of age, which I find far from perfect.
>>> 
>>> 	It is like having a different Ethernet protocol for UDP versus TCP.
>>> 
>>> 	The article must be missing critical information or the writer doesn’t understand TCP and/or CA.
>>> 
>>> Mitchell Erblich
>>> erblichs@earthlink.net
>>> 
>>> 
>>> 
>>>> On Jun 4, 2023, at 5:53 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>> 
>>>> announced by nvidia here:
>>>> https://www.zdnet.com/article/nvidia-unveils-new-kind-of-ethernet-for-ai-grace-hopper-superchip-in-full-production/
>>>> 
>>>> I have no idea what an AI workload looks like, familiarity with a ton
>>>> of DC l2 protocols, and there are hints in this post about telemetry.
>>>> 
>>>> Anyone have clue here?
>>>> 
>>>> -- 
>>>> Podcast: https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
>>>> Dave Täht CSO, LibreQos
>>>> 
>>> 
>> 
>