Re: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt

Ruediger.Geib@telekom.de Tue, 30 March 2021 10:48 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962FE3A0883 for <ippm@ietfa.amsl.com>; Tue, 30 Mar 2021 03:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.418
X-Spam-Level:
X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=telekom.de
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 2da_OXbmqS_I for <ippm@ietfa.amsl.com>; Tue, 30 Mar 2021 03:48:48 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 2A72B3A086C for <ippm@ietf.org>; Tue, 30 Mar 2021 03:48:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1617101328; x=1648637328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6dYuqqE1uB/RvqWp0eX7e0+jghP8ZqIzoTU9ZCCv5iI=; b=Zh+3elixeOlOx9nM9BhJHohsu2gBY6re0+lzk9GKoAnVTbx5m5pBeIy+ pAOQubOiKcbnZdJYsqS3FjI7fiVZxf/ds4Fs0HOAOByxF/qzkmmEMO3+Z Yi18LWXx5IkKw0DpAx+aBcUUT4FHDbGIU/O8WQk2CTPXo0P9sJs4JPJlE he/+EoWo1eTqgUxwYZOD0dNl5hw0ZvjQ4ZZ8FbUQpzugiT7wV3GItql7r UGDJLU9N4CIa9Sdf2eoIn1G0BOAdXOnoL7xlsHr5TJkWhKcVBkQWQ33oZ 8sLZJ05UAJtHS0yDgPO/IcZ1q/Q7qFVWVzM+mis+Ty2Htdj4qz+yMKUoi A==;
IronPort-SDR: GmYcOcC9tq8wzNdxAELyONfQdN0ldncnvOlG6vc8SaAjq/6UNbcJd8ik1TLH6tYYw8cJt2TySP bIUqn5G0Cblg==
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AJnqCAq3EsXlni3rerw+phgqjBa52eYIsi2?= =?us-ascii?q?QD101hICF9Wvez0+izgfUW0gL1gj4NWHcm3euNIrWEXGm0z+8W3aA4Bp3neA?= =?us-ascii?q?X9omOnIMVZ7YXkyyD9ACGWzJ8/6Y5JSII7MtH5CDFB7frSyAOzH888hPyO96?= =?us-ascii?q?61jenTpk0dPD1CQYsI1XYBNi+wFEpqSA5aQb8wE5SB7sRKzgDQCUg/RMK9G3?= =?us-ascii?q?UDQqz/vNXNjp3relorABQg5QmIg1qTmf3HOjKf2QoTVC4K/Kc6/QH+4kzEz4?= =?us-ascii?q?iqrv3T8G6g60b99JJT8eGRredrJMvJscQNLyWptwDAXvUeZ5SjpzYzmee19R?= =?us-ascii?q?IRveKkmXwdFuBSz1+UQW2vuxvq3GDboXQTwlvv00WRj3emgeGRfkNHN+N7iY?= =?us-ascii?q?hUcgTU5iMb1bkRv8wrrgfp06Z/Nh/OkD/w4NLFTXhR5zWJiEEvjPIJiDhnWZ?= =?us-ascii?q?YeAYUh8bA3xl9fE5sLAUvBmfgaOdRuF83V6bJ3dl6XfhnizxNS6eGsRXg6E1?= =?us-ascii?q?O6RFEDsKWuokNrtU1+pnFoovA3rzMh75Q7cp9e+qDtDc1T/o1mf4szQ4o4Hv?= =?us-ascii?q?sLRcusEGzKRnv3XV66EBDCLuUqKnjNo5n47PEe/+exYqEFy5M0hdDoTE5YnX?= =?us-ascii?q?RaQTOqNeS+mLlwtjzdSmS0WjrgjutE4YJih7H6TL33dQWeVVEVlde6qfl3OL?= =?us-ascii?q?yeZ9+DfLZtR9PzJ2rnHohEmyfkXYNJFHUYWMoJ/vE2RkyJucCODoHxrOTUfL?= =?us-ascii?q?LyKdPWYHEZc1K6JkFGcCn4Jc1G4EzucGT/mgLtV3TkfVG68ol3FKTc4ugP2I?= =?us-ascii?q?kAPoBBqWEu+A2Ez/DODQcHnr09fUN4Lr+iuLi8v3OK8WHB6HgsOhc1NDcM3J?= =?us-ascii?q?zQF1dx4SMaOUL9drgO//+Ff3pJ4XeBLhhjC8ffEAtVoUVr6bu6RqbgnhwKOp?= =?us-ascii?q?aCCCa3nnETrHWFQ9M3gauY//rofZs+E9IhQ6x+FQLCEhRvggZ0oGJfaAsJL3?= =?us-ascii?q?WvUA/GuOGAttg5Fevff95zjEOAOshPs0/Ssk2auIUyXHcBRiWvVsSWmA4qQD?= =?us-ascii?q?JRijRKgvUiqYvFvQzqBXo0gew+PlEJVX+eB6heCh+ZIK9OnKrwRQ12RWCWpD?= =?us-ascii?q?CThh0pYFD2/0EKimGJF1zIRdj7Rn5m/lFRyOLD7U59fGT1RTMCVllK9alGUV?= =?us-ascii?q?ngllk2++mRfaa323aWcTI5s5MgGQCARyATLANoz82wzziPll+5ZCsb76RrA8?= =?us-ascii?q?iYNpMfSfXo/k6VQbf4yp0uF+NI/ZpjKdDluvIKV+XaYAOOMDbkEYoSqnmoj2?= =?us-ascii?q?dgNy9upHY+l/T0nBXj8WijxXY6ReHfOVJ8WtggUp6hxnmhQ/aDy5Nii90p+e?= =?us-ascii?q?O2L2Xqc9aDoJunIgJrO1fWoWSsSfsvpo0RtaUutKFrF52eVTfTznlI0FE/K8?= =?us-ascii?q?jz/XluDJhT8fTEOoV1edYVdD8c9l01lM6XJE9uqxfoGIYFDBkQpm6eO8nM76?= =?us-ascii?q?vDqLIpDEHErAzsOUOH+ykY+/veRSOM2bMTFqpYGxUZVGEsrHB5uO+SfYzZDw?= =?us-ascii?q?unM/tO+1e3KXexer5QQqrtI8Rbkj9qp9WT2+OHfSvx3w7d+SZhKqVV6mC9XI?= =?us-ascii?q?e8BhmPFeMgya36BX2cxq+xpMi9gzf8RWHlNwAWhYhZeVcRacoGgD84l4Ez2j?= =?us-ascii?q?WzTKuyok9NqSop3Rh30lr2no6h6yPHGEsDNwvTiJBfRyNSPXiFlt6ty5nS6F?= =?us-ascii?q?3tpDxenYDeH0JRdMxUE9ceToLrPz5jQPJgy4KA7u4qmGBfex8gAG43lSDl0+?= =?us-ascii?q?5n1bm/3u/OW+eKMwagBXsRvThfBoB1mSQ3qWZPN8imhKjNFjkqKg=3D=3D?=
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 30 Mar 2021 12:48:45 +0200
IronPort-SDR: Qx1H5y8rg9GJcyREF/FzF8/AN43/IKHk3LQTvmBARhOfLm2JhjMCeFr4/4zkk4NW8FqunhqUWF vTzSoFmHsuxqC2ThBLAfAp9K0YnhSgbCM=
X-IronPort-AV: E=Sophos;i="5.81,290,1610406000"; d="scan'208";a="284044665"
X-MGA-submission: =?us-ascii?q?MDHmA/DY0iqXUCFPdwGM4fSpFCpOcMky1sO6h7?= =?us-ascii?q?OzzVurUJtLXWVTbRsbfGbGKi03+5fBI9joyahQPlVefagW2zoKTprJ3O?= =?us-ascii?q?OwjK0pwAd0Q3aBZ8Eo7RjBG4swDrLzpAD49EbdX3L9ER0Hg3ezcsdf4J?= =?us-ascii?q?FLGq4Bosg71UB+rSTUxM+GXw=3D=3D?=
Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 30 Mar 2021 12:48:45 +0200
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Mar 2021 12:48:44 +0200
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 30 Mar 2021 12:48:44 +0200
Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.177) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Mar 2021 12:48:41 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iSPEPH2yqQK3wjZENMkVaNg2aEl8GeXpgxBUrrLqohzWG3echgEWtDGFduus2ixf1a+z8t3Lhxh0ZrWOYLmiyaLAQUZ0QrAJQPYnqnFR+Jy1fg4hUi6NxKiiNL7rloQPk1s7x4ml45Sepz6x8LixDYkEjv3fzrkjyBg83qCTezwECcbJw+5gCgcivKTod2lFDUY/qpfDsB1LU459n8bZl2gT3CEn1swcB6Rk9ZawpsEqv35dR/kno0su9GBae02ntcubojDR16a22RPicSJHVDr3oszWrhzTKGNAQcBVCC3urZGCRMzICcr40zaOK0fB/XfwBbcsajjwf04q4G2+BA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6dYuqqE1uB/RvqWp0eX7e0+jghP8ZqIzoTU9ZCCv5iI=; b=YS3TTunab8Sgwl3LEqPiFkSpSp/XTy2aCRaGesZ/u0QU1o27LoMnyNBRUEMzEs/iYImo3TDmJK7HVlu8A0k5QMSZg3r2ywiK7hq61S0S5/esQPpYc39yZAUcD0oy7KXLUspB531bp0iixv7uuGL891HKXWMQTVN+X0pmzk7mELnk4cXVCclqUAstq4P9EO+OWZwwYSlyIdghICDto5k38E/O7zqNDiT92qsSkJPNLzDZpU8WxDoVpRotUSBn44hkj5HKgsc8kue1SNPSDQ6MSi6FJDK73nBQXY/74Auur/DoGJidIWzVJGZZWB6uPndmxz7EiIA+CBfSdcxOgR2MAw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2::11) by FRYP281MB0679.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.14; Tue, 30 Mar 2021 10:48:44 +0000
Received: from FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM ([fe80::e40f:c4ab:db76:e885]) by FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM ([fe80::e40f:c4ab:db76:e885%3]) with mapi id 15.20.3999.025; Tue, 30 Mar 2021 10:48:44 +0000
From: <Ruediger.Geib@telekom.de>
To: <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
CC: <ippm@ietf.org>
Thread-Topic: I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt
Thread-Index: AQHXJOLrl9yneiGOTUyGqQdxAyNF5aqcKKEQgAAm9/A=
Date: Tue, 30 Mar 2021 10:48:44 +0000
Message-ID: <FRYP281MB01127BBC2A94F40783044DFE9C7D9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
References: <161705348048.17388.9380614999436689902@ietfa.amsl.com> <HE1PR0702MB3772E8BA15BFF01315E139A8957D9@HE1PR0702MB3772.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0702MB3772E8BA15BFF01315E139A8957D9@HE1PR0702MB3772.eurprd07.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [84.136.82.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1bb31a8b-681a-4546-ad5c-08d8f36963af
x-ms-traffictypediagnostic: FRYP281MB0679:
x-microsoft-antispam-prvs: <FRYP281MB0679026A2FCC1CA9E7A9F7959C7D9@FRYP281MB0679.DEUP281.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tS6ItJAY70HGcXqD2j9uvtGUfAmjDlhr1ihZ9gDd6QKJzoO2tsuNE4bfG2vlcj7wnSzVSse+hm7AAMvUQIFIbQy+eNmo/vA9/rHIUQJpwLd2lVIe5i4MP+y0l3//69cqOo3azmfXFVw1QA6zfIrypTmwT3xqeOAtUK0pNu0eVBIN4BqapkKRkCdlVeXbz1lLOIiPPjO9X1EfFY0Vct+VFAZoVMjx1oxdXA8b/Kdvonre6CcH+cDoPzNjoFQgQoQ5/+1XoGjry9EKgg1uSUmRpmDmP1F3Fitc3vbaufOpmL9Tp1vrsiTV5sbQtM3i3sKvVlR2zQbK41Zdb1qjMPR8KbdXaefZnkt5kl33WM8FoKGH0UcNNl2yIiuWd8a1xxSyZ/un6efYKRZmCsDp4n3iYgScarpN41o8sFABCHAsEw+h6dRNWAnmzKfWbVf/h7UdvuQfUUcnbey3aRiSeZjPpkVvyqo2pMSuCLDCyLoI7CGKz2lxY+2xjVxIcN7xXVKbUNkvLykvLWROe9jllBSyft8SRXwrnXWmbNob0vCo6P3M1if+eb6H2B/MR43A79mil1q+L+/gFND6POk1Iy8RZeiUmFGoTmISIjIvSespI8IQFCNcm9d2Ne/TBqX8u7mfDBPMdkRkI0SN9Ab53Z9buA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(346002)(376002)(396003)(136003)(366004)(33656002)(86362001)(2906002)(8676002)(26005)(83380400001)(66574015)(9686003)(7696005)(8936002)(55016002)(966005)(66476007)(76116006)(52536014)(38100700001)(71200400001)(316002)(478600001)(6506007)(53546011)(5660300002)(186003)(4326008)(64756008)(66446008)(66946007)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ALfVrOsvMBL9Ctp0bjdgvgoDZzFoGaVFNH8dcug5Fd9zjZ6tL2TCiHja8ykDlYdZXa/9LKCt4CpPTVeldjvjvKafh5QFvksL6fe8hhzJtLSY6tgXzH23mUbtegKROtEiVtr6kq1rQ9+M2lB9sq6xEal64l75JPzz7xkxXtvStTLP+pJtG//sQ814QB5j4GBrt7Ztf/jqjxtmr/3cAoKry3+f0JxvaXpTKRa9f8omTsUxW2QG6a89LzoEc5FaWbYmJ7m2UtltEO//yzIg3S1EBOPWHt16Ig6XiYkVNDfZj4ScMQTWdz2vlSM2FgP89Lt0Pa/cHsAWDZ8wC4bffXz0yNiXNx7heTa3qYaMgOCWVPTk7kY9c02Dbmisih52aBizvT07RnLzCUfkkbCafhBrv8a5fEHDtp3QtPRQaGmtYaFZ8aJhatwVb4xXTz3JEI7TzLz7t6igpuG7yRQjmCm7oWprvgAgv7q5ej/nqq/+zhwsKLB6g0JLFpLdIwVqXu8Tz4AMxGEWgNZBBx5cP9s6XBzG5/tixWaT/Bjyik5aCxspIMKaWvhD70b99ARfyRuIsRGbNkv/GDwerE2G6MnzRvMa0XSTyYia1pmUAf9wKOIddycch6qGKuMklMn7i9+D0nlxY1ZrgNUUclaK2CQrba3XZJ+aPjBtDmwQrKXXsYiiNemlkC8t0P7QVve/PofFyzXZ2A5lYzboHDOrTaph0Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1bb31a8b-681a-4546-ad5c-08d8f36963af
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 10:48:44.1224 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UpHhdDlyGj46rtnidSien+Z1DMzFanUe7eYWzQ/Jsdva+wJIgfYk4ClsDl7GgG3cLUPmLx41OQ4T3TBI6+uuUpjkrNm1yXFqmOXJd+po8m8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0679
X-TM-SNTS-SMTP: 4A84C0FA14AEB29EDDE5825541BEEADE4E378131DA92ED7E1B2223CE61F303792000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/W_y8F1Se-jnmb32r7KezkddVluk>
Subject: Re: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 10:48:54 -0000

Hi Magnus,

[MW] To accurately measure the capacity of the path the load algorithm strive to load the path so that the one way latency increases to indicate that the bottleneck buffer is sufficiently filled to achieve high utility. This load is not intended to be fair against other applications, it is intended to provide as accurate measurement as possible, potentially pushing other applications out of the way.

[RG] The sender rate adaption mechanism operates by congestion feedback, as do many standard transport protocols. The purpose of the algorithm is not to determine, whether a queue or a policer burst size "is sufficiently filled to achieve high utility", the purpose is to accurately determine the access speed which can be reached without queue-build up and/or packet loss. After feedback indicating a sender rate which has caused congestion has been received, the sender rate is adapted until the maximum access speed not causing congestion is determined. To decide on a sender rate fulfilling this this criterium, a sender rate causing a congestion which can be accurately identified as congestion by a measurement system is required. If you are aware of a method reaching this goal without causing limited congestion, please share.

[RG] I don't understand whether your feedback is focused on improvements of parametrization or on the basic behaviour of the algorithm. The algorithm is not designed to be unfair.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----which
Von: ippm <ippm-bounces@ietf.org> Im Auftrag von Magnus Westerlund
Gesendet: Dienstag, 30. März 2021 10:54
An: ippm@ietf.org
Betreff: Re: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt

Hi,

I have reviewed the latest versions changes and have some comments.

Section 8.1

   If no status feedback messages arrive at the sender for the interval	
   greater than the Lost Status Backoff timeout = w*FT, beginning when	
   the last message (of any type) was successfully received at the  sender:

"w" is used here and paragraphs below. But it is not really defined. Based on what is written below it is an algorithm constant, so maybe it should be given a name. 

So the backoff happens after w*FT. And I agree that with a regular feedback interval that will be working independent of RTT, starting the time when the first feedback has been received. What I thin this paragraph could be clearer on is that w*FT need to be considered in relation to the one-way delay jitter. And the most likely cause here is buffer depth in the bottleneck. It must also be related to upper delay threshold. What occurs if upper delay threshold is higher than w*FT? Is there a potential that a step increases is sufficient to push the buffer occupancy more than w*FT longer, i.e. causing the feedback to be delayed sufficient so that it triggers the lost feedback rather than the upper threshold? I haven't calculated what traffic increases that are possible and if that excess traffic can cause this to happen without additional cross traffic over bottleneck. I would assume this is fine to happen in the initial fast ramp-up, but it should not really happen in the regular ramp-up case.

   The RECOMMENDED initial value for w is 3, taking Round Trip Time	
   (RTT) less than FT into account.  A test with RTT longer than FT is a

   valid reason to increase the initial value of w appropriately.	
   Variable w SHALL be incremented by 1 whenever the Lost Status Backoff

   timeout is exceeded.  So with FT = 50ms, a status feedback message	
   loss would be declared at 150ms following a successful message, again

   at 50ms after that (200ms total), and so on.


I still think that Section 8 could be more explicit about the goal of the load algorithm. 

To accurately measure the capacity of the path the load algorithm strive to load the path so that the one way latency increases to indicate that the bottleneck buffer is sufficiently filled to achieve high utility. This load is not intended to be fair against other applications, it is intended to provide as accurate measurement as possible, potentially pushing other applications out of the way.

The goal of being explicit about this is so that there is no doubt to anyone what this algorithm does, and that it is not a generic congestion control algorithm.  So Section 14.1 discuss this, but I think the document can be more honest here and state it explicitly in Section 8.

Now, I am no longer an AD, but I don't have a problem with a limited scope algorithm that just is open with its intention of being unfair. I think having an algorithm that people may copy without understanding what it does is more a problem. 

Cheers

Magnus Westerlund


> -----Original Message-----
> From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of 
> internet-drafts@ietf.org
> Sent: den 29 mars 2021 23:31
> To: i-d-announce@ietf.org
> Cc: ippm@ietf.org
> Subject: I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the IP Performance Measurement WG of the 
> IETF.
> 
>         Title           : Metrics and Methods for One-way IP Capacity
>         Authors         : Al Morton
>                           Ruediger Geib
>                           Len Ciavattone
> 	Filename        : draft-ietf-ippm-capacity-metric-method-08.txt
> 	Pages           : 37
> 	Date            : 2021-03-29
> 
> Abstract:
>    This memo revisits the problem of Network Capacity metrics first
>    examined in RFC 5136.  The memo specifies a more practical Maximum
>    IP-layer Capacity metric definition catering for measurement
>    purposes, and outlines the corresponding methods of measurement.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-metho
> d/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-08
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-capacity-metric-
> method-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-capacity-metric-meth
> od-
> 08
> 
> 
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt