[ippm] Re: New Version Notification for draft-whimir-ippm-stamp-cos-ecn-00.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 12 August 2025 12:46 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: ippm@mail2.ietf.org
Delivered-To: ippm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 590485320FD9 for <ippm@mail2.ietf.org>; Tue, 12 Aug 2025 05:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=erg.abdn.ac.uk
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh4DY6zKGaGr for <ippm@mail2.ietf.org>; Tue, 12 Aug 2025 05:46:24 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by mail2.ietf.org (Postfix) with ESMTP id E35225320FD4 for <ippm@ietf.org>; Tue, 12 Aug 2025 05:46:23 -0700 (PDT)
Received: from [192.168.1.130] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 366561B0013D; Tue, 12 Aug 2025 13:46:21 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=erg.abdn.ac.uk; s=default; t=1755002783; bh=fwqVK5z6szLvj3/U6bT2Sgt05am9g5sT9k2h5uJ0aL4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=K0ASlEivMgTUeLCy9jhjgKt1Q8sYNMUSD2qcDTjiYTVoOyyRUsYOivO0zQjdFgQTc +VY31OXNBFKpgmLonTHUo6ZxjLjwUBKhAVCYOIRCfUk8R+J5Uwo61hJQmOc+lf3N0N sIki1+DrEIOKIR5Bykfi6rgehdKnNWbvzTzPorm2ADIviduDiFH9npxi41P9sSjEn+ +zJYtYFwUlbTlP8GTYMZAxRqqXPUF95q5qSkUzhjHvX0cbNR0hH0WiHKHwlcWkbXI2 ncvhKDapYfcFdi86V1IMaoRzlvsvr3LFdCsy2+7z7kB17fZIDJTjJ7efFPwd1w8QEq ud0DB6n6YBAaA==
Message-ID: <a1c3fd81-02c7-4e75-bad9-a9f30052f758@erg.abdn.ac.uk>
Date: Tue, 12 Aug 2025 13:46:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: Ruediger.Geib@telekom.de
References: <4b847838-a3a9-4ac3-b2e5-890c3a6e6af4@erg.abdn.ac.uk> <BEZP281MB200700DB2A3273AE6AC28F929C2BA@BEZP281MB2007.DEUP281.PROD.OUTLOOK.COM>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: UNIVERSITY OF ABERDEEN
In-Reply-To: <BEZP281MB200700DB2A3273AE6AC28F929C2BA@BEZP281MB2007.DEUP281.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: XT6ZPBZI5GL75XXRQVF7COY4C3BRPNMX
X-Message-ID-Hash: XT6ZPBZI5GL75XXRQVF7COY4C3BRPNMX
X-MailFrom: gorry@erg.abdn.ac.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ippm@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [ippm] Re: New Version Notification for draft-whimir-ippm-stamp-cos-ecn-00.txt
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/FSnkI9PoZhN865gI1VLsVgLw1AY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Owner: <mailto:ippm-owner@ietf.org>
List-Post: <mailto:ippm@ietf.org>
List-Subscribe: <mailto:ippm-join@ietf.org>
List-Unsubscribe: <mailto:ippm-leave@ietf.org>

On 12/08/2025 12:44, Ruediger.Geib@telekom.de wrote:
> Hi Gorry,
>
> if measurements by creating load or congestion, respectively, are part of the drafts functional design, your comment addresses the reaction on "CE". If a measurement creates congestion, should there be an additional functional specification how to react if there's never a "CE" mark in feedback? You mention some "simplified load control" in the "CE" case. Is there an additional need for a generally working congestion detection and for a simplified load control? If the measurement is designed to induce congestion, to be clear.
>
> Regards,
>
> Ruediger
>
There are indeed probably a few things to explore.

I think you may be heading in an interesting direction, if one sees loss 
but no congestion-marked packets for an ECT() flow, that would seem like 
you either have some non-congestion loss or something unexpected.  This 
sounds more like a CCWG area of expertise, but the framework under which 
it operares sounds like IPPM.

Gorry

> -----Ursprüngliche Nachricht-----
> Von: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> Gesendet: Dienstag, 12. August 2025 12:55
> An: ippm@ietf.org
> Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> Betreff: [ippm] Re: New Version Notification for draft-whimir-ippm-stamp-cos-ecn-00.txt
>
> I think this could be a useful draft, and it is good to see support for measurements on the return path.
>
> One thing that I really think this I-D ought to address is that if the tests generate an appreciable load (which seems likely to be important to measure congestion marking), then the flow that advertises an ECN-Capable Transport, actually needs to follow the rules for flows that are marked in this way.
>
> This means the flow needs to detect and reflect any CE-marking (which I think this spec does).
>
> It also could mean that a tester ought to detect (and ignore) CE marks when ECT is not set; but more importantly when the flow is marked as ECT(?), I think the source now must REACT to reflected CE-marks to reduce the load it generates, this could be a full ECN alagorithm, or perhaps could be a simplified load control which might make the measurement easier to interpret. I'd be interested to understand how this could be realised, and see more.
>
> Gorry
>
>
>
> _______________________________________________
> ippm mailing list -- ippm@ietf.org
> To unsubscribe send an email to ippm-leave@ietf.org