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

Ruediger.Geib@telekom.de Wed, 31 March 2021 09:31 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 4E29F3A21BC for <ippm@ietfa.amsl.com>; Wed, 31 Mar 2021 02:31:14 -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 GS_6RAoSjmhb for <ippm@ietfa.amsl.com>; Wed, 31 Mar 2021 02:31:10 -0700 (PDT)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 4FDFD3A21AA for <ippm@ietf.org>; Wed, 31 Mar 2021 02:31:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1617183069; x=1648719069; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WzPJw2HYtzuv5x7ikhkxGoB4poUTPgQxje96ZsjVWMA=; b=McPsT2mfVFMo1WdhfQ6F6EjhY1BrwolMoEiriJvpMXPsNIbfZpAe788E lw0wecihvkhDmK1wmcvo1UaW4zYNiFfDcLjLaOYWeQHf3QyI80IuaU364 RB5MXxv4bUg2kbO0LigVrm4oiRqBX1R5cmPPiSKgPd2rpFHMtG+8PqbdQ CKafWkHvBHUx3XZOqZgNf+OVTy2e2s7madt6jOkC+QanePmo2mnpjc60p L6EFOu4srKXr+0162NUdiBX357P+VjIykXSTowr1IAejHqW1kn5gdwd3/ 7dMbTPZLOMnFg/LESp8JmF8MM1XajIrdPC74J0J8OIsLda9ARspmQla1E Q==;
IronPort-SDR: BwUfrs0kM3U7cAhEwkEntDI/td6YRrXi8KoPl/OEkWEP9Yb6+ZefkA405FWYp7Aj5WeFlfeX0P hG67kQeJl4ZA==
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A10MFN6mSBV82bbH9/ivNj5tjlzHpDfMtjm?= =?us-ascii?q?dD5ilNYBxZY6WkvuiUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNhRouKdD?= =?us-ascii?q?LN/E+lNptr44en+T3vHCXi6vVQvJ0QC5RWIObbSWJ3hcOS2njAL/8JytOK6b?= =?us-ascii?q?3toO/YwWtkQw0CUdAX0y5SIG+gYzNLbSNBAoc0E4fZw8JBqSapd3h/VLXzOl?= =?us-ascii?q?AuWe/fq9rX0K/3eBJuPW9/1CCihS6lgYSKYSSw8QwZV1p0sMsf2EjD1zf0/6?= =?us-ascii?q?Cy98y8oyWsoFP7z49Rn+Lm0cYGPuG24/J/RAnEriaNSMBfV6aZvDYzydvfsG?= =?us-ascii?q?oCtNXXuR8vM4BSxhrqDxSIiCDg0QXhzzoigkWKoTL28B6Txb2fNVRKcbs9ua?= =?us-ascii?q?tjfhTU8EYmtt1nuZg7q16xjJZLEQjG2B30+tmgbX1Xv3Cpqnkvm/N7tQ0vba?= =?us-ascii?q?IiaaRcpYFa3ERZHIZoJlOI1KkbEfJjBMyZ2fBOcVnyVQGogkBTxrWXLwsONy?= =?us-ascii?q?bDYlMFvfWSyCUTtE8R9Sol7f1aulkpsIggQJ1F/f7FNKMArsAtcuYmKYZGQM?= =?us-ascii?q?sRS8q+DWLABTjWNniJHFjhHKYbf1rQtp/e+twOlbqXUa1N6KF3tIXKUVteu2?= =?us-ascii?q?J3UVnpE9ey0JpC9Q2IaHmhXA7q1tpV6/FCy+fBbYuuFRfGZEElksOmrflaKN?= =?us-ascii?q?bcQeyPNJVfBOKmCmfyB4BT3UnbV4NJIXcTFO0Z0+xLBm6mk4buEMnHp+bbeP?= =?us-ascii?q?HcKP7GCjA/QF7yBXMFQXz9P8NF4ke3WmLpgRTYVn/3E3aPoq5YIez/xaw+2Y?= =?us-ascii?q?INPopDvkw+klKi/PyGLjVEr+g3cSJFUe3au5L+gVPz0XfD7m1vNBYYJF1S+q?= =?us-ascii?q?/cX3RDohJPN0v1dL0EqsiOYGw65grXGjZPC+ftVCJPrVV+/qy6a7aKwzo5Nt?= =?us-ascii?q?6hOmWGy30JpHyLSJ8YkraZ5djsf445CppOYt0sKSz7UzhO3Sp6omZKbwEJAm?= =?us-ascii?q?XFECn1tKmjhJsIQP3Ee8JkmwetK85MoXfZvUGRzPtfFkczbnqLa4q6kAwuTz?= =?us-ascii?q?1bihlN6KcZmqOHgivqA3A4mv4EPFpFb3m3DLpKAB+eXphdnqnmdWhLPDS3rA?= =?us-ascii?q?3fryt2W2Lxs20Om2TqLESvCLn2K2sYnkod74HH3xdfcH6Hc0d5d3Zg2LcNXl?= =?us-ascii?q?juizJW2e+PbaH2+XCAc0Zq+It8DBj1JR8bIgZkzJSM2BmJsi2TDGhO/ORMAs?= =?us-ascii?q?XtSJI5c7/S3XuxLpavjq9uJY4AwL9VcO3L9tUtbNjaQSupFVrDerEU8gSIu3?= =?us-ascii?q?coPzR1onE4kfXunAbo9nS8wWRXO4uZHH12A74cON2S9G7iWrKB14h4l8s8ua?= =?us-ascii?q?+qPnz2ccPu89CSUxdTbhfSq3WxVecmtNRdur8zrqJ6G/DgIHn1/WAC2BU1N8?= =?us-ascii?q?HvkkwCBKx9/bDaI4dqO8gfYThQ8FZslNOBKiIQw0nLK/57eVEmlHnAOdyVp7?= =?us-ascii?q?LOtLo0G0WE4BLqJkP3yVwdw97VGy+YkbIKAaM5JmpbLEA69XR55euHM4ndEh?= =?us-ascii?q?+jee1P9EezW0XNN4N1WeyAA/Edvxx669aHk6uMey301BvZsDF7LqhNmlzXAv?= =?us-ascii?q?+aEUaJA6pF4ta6MVODju+2+8a1li7wUib+ZEICh4FJHHZgKPhrm30nlskw3S?= =?us-ascii?q?ezQKCs/R5gnFta/D19llninoKh+3zWGElaMQvfxpVaNAMjfUSgnIDA66yf0n?= =?us-ascii?q?+4/T1OnZ/EH01UdstVG9cRQpPsRh0eafQ4rfqt5e43ni9HYB0yFGYyhzD2wv?= =?us-ascii?q?N+0d6CqbnvcvynDW2tJEkI9jFEDJNlhyAnqWlPdM6l8JK2Cz9nWNIgEr84/Y?= =?us-ascii?q?BZkDVgt1j14RkddnxWx0EV6r0=3D?=
X-Mailbb-Crypt: true
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 31 Mar 2021 11:31:06 +0200
IronPort-SDR: rXnPfkV2NUBkEPJ+FI03uZg9UXBUcpSqeTfk/Epy8W8WUYj8ANQV+hcqGe8eEs8fI6RjZ5IEUV Z6PesZNsXohA==
X-Mailbb-Crypt: true
Received: from he102090.emea1.cds.t-internal.com (HELO he102090) ([10.162.178.105]) by qdezc2.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 31 Mar 2021 11:31:06 +0200
Received: from QDE8E4.de.t-internal.com ([10.171.255.33]) by he102090 (Totemo SMTP Server) with SMTP ID 634; Wed, 31 Mar 2021 11:28:09 +0200 (CEST)
IronPort-SDR: +xqiYCv8nuXkd4eHb1FHfPi6iiv1Dya+uLFQTwygdlv2fLwwr77KPTwJpt2WrODmMfQvbSYvaS QRybAlcQVrd4lPqt3FEgAxuwmQIf747wo=
X-IronPort-AV: E=Sophos;i="5.81,293,1610406000"; d="p7s'?scan'208";a="981366732"
X-Mailbb-Crypt: true
X-Mailbb-SentCrypt: true
X-MGA-submission: =?us-ascii?q?MDHOWC8A79QjoixXbUVRLiASwkIcCa++yCwSzn?= =?us-ascii?q?aYHzwBXxTPzOGy4kEuai0l81+e0ZqoWIkQZ/IaBikVuMbm/ExHJj4Vu2?= =?us-ascii?q?P0hiu0DrzwNU5Tcz/gFuTRIRxXU4k6zkmrF04uOj0dkoROc0F/8zTrBV?= =?us-ascii?q?myHumOntfSkfSDYXqQ1cMKsw=3D=3D?=
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDE8PP.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 31 Mar 2021 11:31:05 +0200
Received: from HE199745.EMEA1.cds.t-internal.com (10.169.119.53) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 31 Mar 2021 11:31:04 +0200
Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE199745.EMEA1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 31 Mar 2021 11:31:04 +0200
Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.171) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 31 Mar 2021 11:30:39 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bSxjVL8n/1er7IMNDBVCqGkmosR2vEZ2cIeq0mNYqIeMQxLjr9IH5oAuE8yKFXCidZrGY4Ku2AxB3ajYJa+TroA/38MNm8u8Mp3/MZ9MD/vAaJTnKWA2rOox3LtwbMUpt+/IoLjBnjRYkC7zAhUIysnHVpbhZgCPdxTjAyBuEjwiKefl0cwiI/y0WAEmGkMqRXFEe/UI7Q7TcNavdgC8HVKvrn/smpD8+y7fw/qWGqMhBC0VGUFDrfMniDW5N9s08HEgvxFW63Pmk6A7wtRgqivqFhcERz/Ik7GkVDdigV1Y+C1oeaXYletX1pgIpeiVO/K3sbq+teC0rZyXrrxsgA==
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=EUpuO+rRMWT5Xg5OA/4/klDjr2PdsHSMxE1UZOaPBzs=; b=MIvKhaY+wwR0dBYHkVneHa7rKGaR3bhTzbQIdZ2USWbXTZldInYSVIG+50KSsnxokW8RIQ5+85oIjIye/+86wzvhMxWEsRxAeoKePZO/VoVyt+Q68yK4LYgz5punPYv+dHohg+s40Dtft7fJW+g7UmYh8IAJwUYRqsWzJ8u9P50EiANG5IXT447OUg2KsC0bJBbOpC0xrt9HCwyQFuJX4sAo6Tp1QPX3wgBVdXoPake203f+5nA7ELKsJ2wRQVehmaV7NifVEwEwrYwBcWlDNX+NN16az1DJYNYzp3MV9oPEuOja5g8bO9A08HOK5gAvm52XCo+hVHGH3WW/XkrB1Q==
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 FRYP281MB0206.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.15; Wed, 31 Mar 2021 09:30:16 +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.027; Wed, 31 Mar 2021 09:30:16 +0000
From: <Ruediger.Geib@telekom.de>
To: <magnus.westerlund@ericsson.com>
CC: <ippm@ietf.org>
Thread-Topic: AW: I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt
Thread-Index: AQHXJOLrl9yneiGOTUyGqQdxAyNF5aqcKKEQgAAm9/CAAWmVgIAADyuA
Date: Wed, 31 Mar 2021 09:30:16 +0000
Message-ID: <FRYP281MB011208657C5A83AA34F137829C7C9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
References: <161705348048.17388.9380614999436689902@ietfa.amsl.com> <HE1PR0702MB3772E8BA15BFF01315E139A8957D9@HE1PR0702MB3772.eurprd07.prod.outlook.com> <FRYP281MB01127BBC2A94F40783044DFE9C7D9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <201af4d37914dfc0a87204b82c6db3c236acea6d.camel@ericsson.com>
In-Reply-To: <201af4d37914dfc0a87204b82c6db3c236acea6d.camel@ericsson.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [84.136.91.222]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 92d8c865-6edd-4fe8-1e24-08d8f4279849
x-ms-traffictypediagnostic: FRYP281MB0206:
x-microsoft-antispam-prvs: <FRYP281MB020657AF200FF0BE385153559C7C9@FRYP281MB0206.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: JCa46XVT3ERvcDBsppdLxFmfxLtwz3yW8ciAO372vTU2RVXConfEAcGX+q7ErgiUhx2/KM/yJ0IOmL9VDtm1Ltu/GtKZ7B56NLQeScUCvqTUeeUIIP0vj2a2/vr+RRtBSvACfIg3Z7pyv81w9L9jzRRmr7Ifmmrkq0RcRwmQvO4f9QRtySlDBOFdGdAVLCdkEbJqqCEf9dcvQ28O1auOdxon+hQj5RPYVCpHWx4q0NOnWMFFju0kathbBcdqOmaHESaSN8j0sypCH6NMgacVtZZkFXPtW/1xCmPtcFRwADbIWOIS9XpXO3gZcQG4nAw2PsjCUtxvyMQ+J75mibcbanyspIGUZy2lmrYh0hLyucAVMt+pIX3XoYtrsY2+rnBkYouwB7ZA1sKn0LM+L29nNpKsb0WOx7xFkauI5JOI0vbu6cwa/PGJbPd40UILNk8UMA5zX0B3NbBa5IJDE46Cjqt7vCxRqMdA/o4aJL60Czj2XDwJVlcszMmTJ1RIzrk+6hrmp5ZkH2bdmys9w+rrq5Blm4GKRbABnCY8ZwweUsXeeqIaeGmRTl8g+PRyTxgqDfnfpNOp9xuItQVREWbknvY3LomzLKgJrV2SfPlzqWhq1KVugmbna7xcsFe7FP4GMrc7G8v9XAkHzc4Utx3Lp6bOO9A93AfvJFNs3yMaJro=
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:(376002)(346002)(366004)(136003)(39860400002)(396003)(99936003)(38100700001)(9686003)(55016002)(83380400001)(33656002)(52536014)(66946007)(316002)(85182001)(66446008)(66476007)(66556008)(64756008)(66616009)(86362001)(71200400001)(6916009)(8676002)(4326008)(186003)(26005)(66574015)(478600001)(8936002)(7696005)(85202003)(6506007)(76116006)(5660300002)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Q08xR2YvLzdoTEM0NENybit6aG5NRmQzb2ZYYStWWHRQSGlVeFlFU2RhV1dY?= =?utf-8?B?TitxelE0Zm9LOGFwNUNjS2NCOW5FR0JCNlhXc2V0YkNqQVREbTVOTmk1QVhT?= =?utf-8?B?UVpaMlRhclBjSU13cWJzZXAxRnJNOEJZWCtTaXFsd284aDBBajFnN1YrYjgw?= =?utf-8?B?QjdldEtaSWJ5U1NRVldPU1lrekZXblBDR1dMVWl3SEFqV3ZiZStLZkZ5U3ZU?= =?utf-8?B?bVVQemFoV2thRGttRXJiRThaRVl6M3ZKdGc1U3g2VTRUS1hRZlJmNFB3OUJ5?= =?utf-8?B?eVZTV3pMSlFmNHZGVG4vZHZwMkhXdFYrTEI0MjBOWnZYcnBPd0ZOT2VPOGtN?= =?utf-8?B?dHFvTWZzUkh4MllSbWh3bHk1eFk2VjVsU1d2My9vMElZYVZGVFo3a0VPOWRN?= =?utf-8?B?RjFPOWFGL3YrU042VzhwZkxLTktuTnJENVhvWXNYOGNHWGlVYnU5eWFML1Zu?= =?utf-8?B?RWJsR2JlMjNKYzJFZnZubzNBQ0xrNHg0RnBRaWZSSUNGSUdPYWd6QlJVNzdC?= =?utf-8?B?dnhJbjZWNnR3eVFhMktsNm9ZRjFCYnMraVZSSjNMVjNmOVBub25tZlZqOTJ5?= =?utf-8?B?Zy9RMTk2VVF3Z2t3cHIwREFyTDFKczNzVDd3RHB3WTYzdWtsb3ZoWWZ5bkJU?= =?utf-8?B?SHc5R3FCbzBKb0tEZDhoZkVJeURJNTZPSXpnVjJPMzV0OXBFbFFuOU93Y0NS?= =?utf-8?B?ZmVsR1BBZ1laaDdMTEtEQWNNeXBxa2F5UzVRMm9pcFNRZWpObDcxd3hrZVZM?= =?utf-8?B?Y0xnOGNkRmxWdEdZSWZDRkJXRndaTS9WZmhkN2pUVEZYNVp0cDZJMHdqQzFC?= =?utf-8?B?VnpXY0lVWklaTFl6R0QrVitQc01ZcHMrenNQZmY1VzhVNFJtR0dGMFo4aWs5?= =?utf-8?B?WlV4VjVJMml3NjBLRkhtS1F2RDduT05xK1dOS2ZxUkIwWjRlREZBMzF6WXZP?= =?utf-8?B?SkgyaFNvNm10QXJFTDFJS2JPdmdSeEE1bVhaODBpWVp1SEZIZ2h1NmhQdHMy?= =?utf-8?B?MmNNV2ljeGVUclEvQUtWcHVoYjM0cEdOblVtdGFzQkNmaWVwK2Via25BQm13?= =?utf-8?B?S09jY3lJMERQZXcxNjBBWDlxSExxc0FRNWZmTHdQU3pPK0NYbkRZdnpCV09u?= =?utf-8?B?dGU3Z1l1NWFqYXZiS0FJYWYrVjYvbUtvOVJlaXZwRG81QWtBMXYvR1VTc3ZW?= =?utf-8?B?dENwNDFmWVVjeU1SZ0MyYk1BTys0UGt1dVBXdVdRYUdnSWpUelFubndhVWl4?= =?utf-8?B?TXpWTjR4N3U1d1F5YUlmMEV0SlV3VnNqT3dZWTVTd2I5TmlaU24yeE5kdjdM?= =?utf-8?B?TFlmU2hJc21Xdi9ZRjgrTHF3UTVIUXk0ejY2cS9EVVU5aktZOGh1a09mQlZo?= =?utf-8?B?U25vY1E2YWc1aitVN3RTZitvZU1OMGZiTTd3RG5aT2JvQ1BOK2RyNUQvbFVQ?= =?utf-8?B?bjlJQ3IwZkRUci9MaDZWYisyVUtVODRTcUJka2JSc0pPTW5mYWV6QkhLNnJv?= =?utf-8?B?QUZKYXJVY09iTzdCR0RCOVY0QU56V3RDcGNwUmhNeGhZeWZaMFUwc0J2eTFy?= =?utf-8?B?OEVrL2h6eEhLMTJ2bEluQWJVaG42S1o2a283WmNXU2txL1BSeXUxVW03TUtr?= =?utf-8?B?TUdRTFhxTWVtNXc4UXFlM2E4VkNIUldHRjJxV055NmxrVmhidWM5M2hmYmZ4?= =?utf-8?B?cUM1T3RFZnl1L1VIcVJId0ZYV3JQdGdEMFJ5NUU3YXJDWkxNNFBwNGVycHhH?= =?utf-8?Q?Bc7PeGkw46Los+Q1TG1m8/uQhaUz5QS+07qrhXW?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0004_01D72621.2EC97590"
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: 92d8c865-6edd-4fe8-1e24-08d8f4279849
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2021 09:30:16.7192 (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: WYSnbKPqrrOsjucdMQZDZEx3ontPkzSmmpYk1DC5B6pBWSriFqYxjP2+UZTii4QvjPC8uMTIuPSJMfZTEZ3yZyGw+6K5mO3AlWt+YkB1PPU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0206
X-TM-SNTS-SMTP: 594678EF06308B3E922562EE028A7EC92FB641160EFEA15C359E37AE43B5C8C22000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/L2H-o_y52aQLRUxDW3jvCgrWnCc>
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: Wed, 31 Mar 2021 09:31:14 -0000

Hi Magnus,

Thanks for clarifying. 

The scheduling behaviour of wireless shared media is an issue and first results I saw indicated an increased RTT and a rather high access capacity. Store until there's sufficient load to use a "bearer" and then send at line rate. I think that's one of the reasons why a measurement "preamble" is part of the method. As far as I can tell, the above behaviour turned (often at least) into a more stable forwarding, as long as measurement traffic arrived regularly afterwards.

We can't get around inducing congestion to recon that we are "over the top". I'd be happy to work with ECN marks too, but ECN isn't widespread at devices scheduling customer and server traffic with operator connectivity. The overshooting carefully is a requirement, and that's a reason why the algorithm measures queue-build up by increasing delay and classifies it as a congestion indication (as I think do some or all of the latest transport protocols too, without comparing the detailed algos). Fairness against competing transport hasn't been tested. In my eyes, such a test needs to compare commodity speed test vs. competing transport and then IP-capacity metric traffic vs. competing transport. Both, commodity speed-test and IP-capacity metric traffic decrease the bandwidth of competing transport. One of both might have a significantly stronger impact. I don't judge here, as I'm not aware of tests, but I also don't think it's ok to state commodity speed tests are fair, as they are TCP based. Their design goal is to reliably congest the receiver access until drops occur.

Udpst is open source. In general, and not addressing you personally, I'd appreciate all improvements to reduce total test load and test duration, and dealing with background traffic or (more generic) dealing with feedback indicating varying IP-capacity during a single test session at the receiver. If the result is "available capacity" because of such a time-varying receiver IP capacity, then that's the result and the test stops. I agree, that a test should not try to determine IP access capacity "by all means" (and I think neither does the text provided, nor does the implementation). 

Regards,

Rüdiger
 

-----Ursprüngliche Nachricht-----
Von: Magnus Westerlund <magnus.westerlund@ericsson.com> 
Gesendet: Mittwoch, 31. März 2021 09:43
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: ippm@ietf.org
Betreff: Re: AW: I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt

Hi Ruediger,

On Tue, 2021-03-30 at 10:48 +0000, Ruediger.Geib@telekom.de wrote:
> 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.

Okay, I might be slightly conflating two things. So the indication that the path
bottleneck is filled to capacity is the fact that there are some queue buildup.
Loss and queue build up are the two signals that the algorithm has defined to
indicate load and congestion, as it isn't defining a ECN response. However, I
would argue on a number of link technologhies you will not find maximum capacity
unless you attempt to transmit enough data and actually build up some queue in
the relevant buffer. That is definitely true for a number of radio technologies.
The underlying reason can be both efficiency in inter user scheduling as well as
deal with short term radio fading effects. So capacity and high utility are
necessarly linked to me.


> 
> [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.

I am not after improvements of the algorithms I after accruate representation of
the algorithm and intended usage. From my perspective this algorithm does not
need to be either self-fair or fair against any other congestion control
algorithms. And I am fine with that as long as it is clear on the box what it
does. Have anyone run any tests of how this beahves when competing with other
congestion controls, like CUBIC, BBR(1/2), LEDBAT etc? I am not asking for it
but it if it has been run it would be enlightening.

Cheers

Magnus