Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)

Ruediger.Geib@telekom.de Fri, 12 March 2021 14:26 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 C236D3A0A65; Fri, 12 Mar 2021 06:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 ZoBBiHh35tDP; Fri, 12 Mar 2021 06:26:27 -0800 (PST)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 19EEC3A0927; Fri, 12 Mar 2021 06:26:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1615559186; x=1647095186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fcULGPPHmc//vIHePeWF0Q6ZVTyoXmkiQgl4J8BPMF8=; b=SruEvedRJHF7Gz9WkNWVMH+Lv9+NU2bgD0AS7NGepW2LC8BThwGhl3eP dphdA0aGxantj4UWMF60QVHTvpvlJdpM3WphHoLCxNHUWL9dEPot44KlG TyRqc0YRBoXbbJm+TV8QmThTB0XwK+u65an1z2arX7h8/ZSAmNkGWE9k3 qxCkubPKb3hySzU9rusR1iGFtzaBqt5MZ2tDKWDmOEFmX7JC6lDV8CF4U +n+AIF4hQQm1PvLO6AOiuMrAjC9VwWSukfM5DezELxt9xYczzJsz/hAmj lyFdVcW/1hNgUaQspuldqfw06AcZ0iQIJ12CESzw5Ee3PEkGGlZs6SKrL Q==;
IronPort-SDR: 3Cj0E7S+ZBX55C8ur8LKAbuFfRg0sqNQAn3YvS5zNiQjSfSj7P5LhiCfK0Bqw4UNfHDF7VwI2d I4J0o3cjcO6w==
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Axrkx06s+hmgtPzIH8QItOuIV7skCd4cji2?= =?us-ascii?q?hD6mlwRA09T+WxrOrrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOkPIsFJ+Ydk?= =?us-ascii?q?3DtHGzJI9vqbHjzTrpBjHk+odmpN9dWoBEIpnLAVB+5PyKmTWQO9wrzMCbtI?= =?us-ascii?q?WhgunDx3lgJDsaHZ1IxS0RMHfkLmRdQg5aCZ0lUL+V4cRarzStEE5nJ/iTLH?= =?us-ascii?q?8DQuTFupn3hIvrCCR2XiIPxQGSgVqTmczHOjeC2BN2aUIy/Z4D9iz/nxX99u?= =?us-ascii?q?GftZiAu2jh/k/J6ZNunsD9juFvP6W34aYoAxHNrirtW4h7Qb2Fu1kO0bmSwX?= =?us-ascii?q?InisPFrRtlH+kb0QKlQkiPrRHg2xbt3V8VgheOpi788B+Txr2eNUhKdvZpvo?= =?us-ascii?q?5XfgDU7EAtprhHodZ29lmUqoZNClf4lDn9juKlazhRikG2rXA++NRj/kB3bI?= =?us-ascii?q?oEZLdd6awZ8U9Fea1wbx7S1YE9HOFiSPzb/fZdGGnqH0zxg28H+q3SYl0DWj?= =?us-ascii?q?ecRE86vNeJlxBo9UoZ82IogOgwtjMb6Jk4S4Nf5+LCW54Y9o1mf4szV+ZQFe?= =?us-ascii?q?0BScy4BijmWhTXKl+fJlzhCeUuJ2/Ng4Sf2sRv2MiaPLgziLcikpXIV11V8U?= =?us-ascii?q?QofVj1NMGI1JpXtjjQXWSGWyj3wM023ekihpTMAJ7QdQGTQlEnlMWt598FBN?= =?us-ascii?q?fAZvq1MJVKR9juMHXpAoQM+wHlQZFdJT0/XaQuy4sGcmPLhviOBpzht+Tdfv?= =?us-ascii?q?qWDqHqCywYVmT2BWZGUyP0IMlG80C3Sn71iBXcQBrWCxPC1KM1NJKf0/kYyY?= =?us-ascii?q?ALOIEJmBMSk06F6saCLiAHsqFeRjohHJrX1oeA4UWm92fB6GtkfjBHCFxO3b?= =?us-ascii?q?nmW3RW4QsDM0b+d6cfq8ySEFoijUevF1tadYf7AQRfr1N49eacNJqL3x0vDN?= =?us-ascii?q?qhLyadlHscpHWDSp8Gga2d7cL5epc1Z6xWBJBZJEHuLVhYiAxqoGBMZEsvXU?= =?us-ascii?q?nEDA7jjq2jkdgJHu3FbsJ9hw2qOMZQrnrauSyn1JESb0peewTrfd+cgA4oST?= =?us-ascii?q?YRu0Z49LUHhqGc3Ry1L3Ekveg+OFpQSWieDb5cFj6ZbIFMlr2DQnAicU66wR?= =?us-ascii?q?ihzzA6YC7D6lgbjG2JF1zdRdj7Rn5m/k1+/omv2lVubWmZd193cRlBwMZAPF?= =?us-ascii?q?WDnn5y1OSBIoCpw3KNA2Fpot01AXXgaTsWKQgr/dyxyTSPiC+efE9WpakGD6?= =?us-ascii?q?j6F7Qsc7bax3W3DpaH/Jt2SsN8zdJZEJTVldIwFdi6Rjb9FkKrN8ogxxGVqn?= =?us-ascii?q?E5OCN9tXkjlrfy1Af46XWjtURPS8b6MRBoQaoWLMqb6HWhT/GU0I9hhdZwpu?= =?us-ascii?q?eoNH7tA+T2jZ3/fnpGKhnJp3SxQPxtoZdIvbgqvL8bJeiYbRLYkHVG1g45Ns?= =?us-ascii?q?H6iQcXR7l6+qnIPstqc9YJcyxUulovm9LnFjpvjiXmRus/d0oqlXnVIpeA5K?= =?us-ascii?q?fJs6MmBgmZvxTrUGPvshF17rPARW+OxLQaA6U/LSBfb1U98m1r+KeHe5fLAA?= =?us-ascii?q?uneulf9DOBQziAWa4YTLLAFaQbrx587d3NheOReibi0A3bvDdwIMt1giWaaN?= =?us-ascii?q?L3BBjJFf9D8tS8N1jJn7Cj59SriizrDTS8cEYViOR+BAotR9UGjiNnioI50i?= =?us-ascii?q?K/EPOq5k0klkZT+jFhmBrm3JO87GLSAEFBNknYj/xtLHZuG2nNid6A9+6SkG?= =?us-ascii?q?n56nxC35LIEU9LZNFAG9QKVOHMXmdTANlVuKTt5rYlhyRIfQwnAGE9gi3sxu?= =?us-ascii?q?8O58b05NzCH+n5TWryMV0P+TRZFpd5kywip2ZHadW/5/uGE0sqP/9NBeA+6I?= =?us-ascii?q?BQmC9orVa270R0VWQhijAV?=
X-Mailbb-Crypt: true
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 12 Mar 2021 15:26:21 +0100
IronPort-SDR: IfPeIzLtoKcxb4dYVJtH+iUIjNwHYOUPX0fCDJoJPchlk0gEZJ9Y7NplSSc7BkJ8WuXkO3N7EE C1tqM2Yhg3vw==
X-Mailbb-Crypt: true
Received: from q4dee1syvuf.ffm.t-systems.com (HELO totemomail) ([10.162.176.13]) by QDEC94.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 12 Mar 2021 15:26:22 +0100
Received: from QDE9XY.de.t-internal.com ([10.171.254.32]) by totemomail (Totemo SMTP Server) with SMTP ID 283; Fri, 12 Mar 2021 15:26:19 +0100 (CET)
IronPort-SDR: +dSu0UopuW8cMDGJFcNz2tUT/IKkBE8ezGahZ0ryhXs2eZWACKeksswZsn7Hs+cVCljTMFS6y6 N2BATCYyzx12YWWgfD80hES9B1pjdHxyc=
X-IronPort-AV: E=Sophos;i="5.81,243,1610406000"; d="p7s'?scan'208";a="274398560"
X-Mailbb-Crypt: true
X-Mailbb-SentCrypt: true
X-MGA-submission: =?us-ascii?q?MDE0ScF9r8ID696ykmgl8eePQfqL/GZaYpQ9GX?= =?us-ascii?q?HF4a5wUCrE1eMPhDMPMlAzGHc2ySTJIhSOi4egHSxcV9HknOAHgh0VZ2?= =?us-ascii?q?LXFeJ5ysMmKo+t+22RyGNd+aFkE7t9khz9e42Gb5UqatuqkTOCS5Ik4H?= =?us-ascii?q?X+XkyQg2kD0N/yGrnZW53iog=3D=3D?=
Received: from he105716.emea1.cds.t-internal.com ([10.169.118.52]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 12 Mar 2021 15:26:18 +0100
Received: from HE105717.EMEA1.cds.t-internal.com (10.169.118.53) by HE105716.emea1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Mar 2021 15:26:18 +0100
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105717.EMEA1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Mar 2021 15:26:18 +0100
Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.175) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Mar 2021 15:26:17 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jF1viThrbaR4mrCItrnLUCNUNJEGDwP2ZGG0Uf5Si/bY+M+T2k1/KX9TzHJycDXfz/ZZaRLIbAswQ8PhIZ5HucN1q8RV5I/kt7XYbbYWZ5kGlB3RTt0K+dl+3xTU18uWsm6t06pjCYuhGlTGfpjcK4ZlnvzBlPNXd80o7RD1xzSpGFH23tVGw4JoJtCFtp2AK1MnoeZpVY9Y8vy861CQYvN/Uo0xwljcpZOm8iaZy+/dsAUSwAzdQNIhzk2jO9XzaZdX0F+y/kUmEWvqcphjjjHeGOfyu4VTvPmJAWl5f5veYu6TTw+qIuCIzs008ypurJbgtGrYVbXMEh7Z2/kvdQ==
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=lDrpeZZetUsbFlB/joXW1838E8eQnOIIZQ/1w2tnmas=; b=NraB5JZArFZl4TPjcvNLfTktPL2oeI695Xqe8w2W72gfz2CQJWVpTGK6ySi+vgfLbyMge9MuobSouE3WXhOawoyTVoWpCO1gL0OLwBy+n2+1Btiq80w8mWeC6nt4SjbFGlUNRxPQlstnca0TCljkL34S007C0ZnSs1GZGQVSztcJEPDqnqyuN4rKAjPh3v3eAgpmFwqq1zn7m6wqQDZG2WUJoxB8Ino/79CfYn760EOJOzFBo44iaYpLeJ6Rx5pj4QS9TtC6Un2sv5Uu11McKw316BvkZcHOYuJPSk1eTB+TybMyyJdw+55FIjDtAOdLFtqef4NHm3/uXb/1sp136A==
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 FR2P281MB0265.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.13; Fri, 12 Mar 2021 14:26:17 +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.3955.011; Fri, 12 Mar 2021 14:26:17 +0000
From: <Ruediger.Geib@telekom.de>
To: <magnus.westerlund@ericsson.com>
CC: <tpauly@apple.com>, <ianswett@google.com>, <draft-ietf-ippm-capacity-metric-method@ietf.org>, <ippm-chairs@ietf.org>, <ippm@ietf.org>, <iesg@ietf.org>, <acm@research.att.com>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)
Thread-Index: AQHXC4EnvPLzhH0sQ0K8CsiAo8w0/6po9txggAGffICAACldMIAGGjkAgADI6CCAAuLjkIAAqr5AgAAZfgCAAB6PYIAABYwAgARiWICAAJqpAIACxBLQgAHbAyCAAWEagIAACU1w
Date: Fri, 12 Mar 2021 14:26:17 +0000
Message-ID: <FRYP281MB011279FCD4D407B140470CB89C6F9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
References: <161426272345.2083.7668347127672505809@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF01476A0C0E@njmtexg5.research.att.com> <66f367953ae838c8ba7505c60e51367843117787.camel@ericsson.com> <4D7F4AD313D3FC43A053B309F97543CF01476A0FE3@njmtexg5.research.att.com> <HE1PR0702MB3772A66E2C0409F5A69DC7DA95999@HE1PR0702MB3772.eurprd07.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF0147CA50DA@njmtexg5.research.att.com> <HE1PR0702MB377281B141FBB6D63015CC1895969@HE1PR0702MB3772.eurprd07.prod.outlook.com> <FRYP281MB01127EE4544CADF8B6E6E2E19C969@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <HE1PR0702MB37725A93AE2748D0619DB95D95969@HE1PR0702MB3772.eurprd07.prod.outlook.com> <4D7F4AD313D3FC43A053B309F97543CF0147CA565A@njmtexg5.research.att.com> <FRYP281MB01125B1728BCEF1D721B81EE9C939@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <4D7F4AD313D3FC43A053B309F97543CF0147CA9031@njmtexg5.research.att.com> <VI1PR0702MB37757902F5B59F99C5D8F24995909@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FRYP281MB01124DAB19CA73818AE5F3759C909@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <HE1PR0702MB3772AFEDDFB422EE5844E4C8956F9@HE1PR0702MB3772.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0702MB3772AFEDDFB422EE5844E4C8956F9@HE1PR0702MB3772.eurprd07.prod.outlook.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: [87.147.144.6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ddbb9249-2745-4467-ee77-08d8e562ccab
x-ms-traffictypediagnostic: FR2P281MB0265:
x-microsoft-antispam-prvs: <FR2P281MB0265559B99993DA9E77613749C6F9@FR2P281MB0265.DEUP281.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wx4BDsRLZ9Sm4SKaw+121Pvyp+jNjoMam7AojC11ZKJ878TJaZtlD2JaKWGY9WqvEjyB8MehoQPe5Q11EGLx2V4pbd/Jrk2lfwlh7CkDJzBAxxC7PvYapU3B53PcCPglyHZo44e3EKpaksn3eJagjshdczViptsoVnwHbJdOwmTKCh6rv3fEI5WQ6ag3c3RPG0cVe3wMUls02MUPyW1LYHncUVlC7N36c8JJHxMq+9YkY5VDFNtWc63Hub6MVgpz09+0nxSPbu2xhA//GxUL648f7SEG2XYEamPi7Zs6UytjuSSJNQCoNq0X16M3G/gd4+6FSx0kv70sbRfdNqV+0Q4MM00DJZWZ0xQ8y4BNj8sXP36U6LcWmlbDRrm+Ams5tn4hfhdgkf0aNfIwwsMdXO8xKoaAeyngWBq2pu309zlmWuuiUBdH/RLHq8YXxXe4fb07m3spsdy0PvJZMHsfFTFjhvz+9oLdvZ86CtuQmBjJ2AmIFqFgzWWUI3zquOni6vnWLv9jtDYwXN11o+dw5R2NHd1UGWTn8LlW19omqqKhP3DIQyJId5vAjczrcxWG
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:(346002)(376002)(136003)(396003)(366004)(39860400002)(478600001)(54906003)(66946007)(4326008)(9686003)(6506007)(83380400001)(66446008)(64756008)(7696005)(85182001)(99936003)(316002)(5660300002)(53546011)(6916009)(86362001)(55016002)(33656002)(76116006)(85202003)(52536014)(2906002)(186003)(66574015)(71200400001)(26005)(8676002)(66476007)(66616009)(66556008)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?QWxTaU04VG96SE84WUxuT3JwMEhBZjVtV2M5MDYwSEhvSFV6dXV3T3V3emVv?= =?utf-8?B?UFRxMVl5R3JsVmN2bGdtSm52SlhkcHZtODdPVCtlU2JPK3Rrc0VQMFBxS1F2?= =?utf-8?B?Y2FCZ29YelVicXdYOHRSc2VLT0kweW50elBJRElrdWkxTm5kZWtxa1RpVU9v?= =?utf-8?B?SVFha2d1dEFWNjZSNGhoUHNNR2xhcU83M04wTDdQNlRJN0c0NnlvVitpRzhQ?= =?utf-8?B?aTdFOU8wbnFUVlRpUW91cjdudW4zeUlQR21GY1FzTW93R0hkRWVkM3RvSnRm?= =?utf-8?B?cmxxNU52M2Nndnk0S2RVclZFQi9FbzRBNDF6alZSZW9YS1VoM1k1YUdNT3JG?= =?utf-8?B?K3NXSE9lTDR3UUVuR0F6c2dMb1dHdGVJN21xV1ZpbmVvSGlEejloc2daMHM3?= =?utf-8?B?NkRWWjFkV3QzUFE4WXV1V0pvd0NIclZBc3hVZ3NZQ25mRzRnLzJkWXBpdU1X?= =?utf-8?B?ZDBrZ1Vjem14RytmSURVTkYva3pUVlVrQ1pmalArVFlkU3JuMHhaMXUwYnQx?= =?utf-8?B?TjBldDFqYVllWjN4bVRwUzlVK0VTK3pTYk9leUI0bWQwWkhIZEpLS3MveUpz?= =?utf-8?B?SXRPanJ3NmxQVm54WGNnKzdvcnpqRmtwM3J0b2Q0M1hpOXJhZmg2clUvajd3?= =?utf-8?B?MEd6L3p3R05WVEFZZS9oY2ZnbUNPMjRIYmpnZit0LzlDZTBaVlRMdGNTSnF6?= =?utf-8?B?TWtLUGlJQk5UdHNFRWhBOElnbU5YWmFhNXg4YjdZOVlaYm40SmNRQlZEVUg5?= =?utf-8?B?bUZXOWh2Y09YajNFUVNOSUxWQkh4bGVqN0ZmS3NmSjRINHFqc3pwSHJGYWkz?= =?utf-8?B?aXZkT3NLVko0ZjdwK3NqMG9PZ1JaTHl0bDFvVTQyb0J1bDQ5T2JlOU1LU3dq?= =?utf-8?B?STFBY293b2dXb24yRDFVY3k0MUZOMWVibFBrYlM0RlJXQkVtVklLVzFEVjNu?= =?utf-8?B?c0t4dTRPdEl6STI2QUdrbEVRTmljVU1XTTBHcHBqeTcwV0RRT1dqZzQxZ210?= =?utf-8?B?NTlsYzNHZTdYS3V1QnpMMmtTTHJQNng3ZWtsMDhwTGVoM1g4UlMrSmVudDZD?= =?utf-8?B?ZGFxZDBxSTdHNVFBNVpjMXpSMFlyTGZGUjNvaW56YmhQb2NIdWN2dUlYMDFO?= =?utf-8?B?bkhySlhjWlQ4SVJla0dVYlZDbEkyYjZSRVI2aFNEYU42UENNRWllbVFVOUJz?= =?utf-8?B?WTNuMnViUDNScmw1SHN0VW9ST3VkZXRKQ1ZhQnVrYTByNDJTRnRnbi9mSVV5?= =?utf-8?B?a21PclM1ZnBDYTVkWTVDYVI3S29BTkM2ck90WXJ2d0w0SFlTaDVHa0tOa2F2?= =?utf-8?B?RGdJNnJMUjM2K3RtOW1TME9Ud0hSV1gvRnFSSjQ1VlNvMWFsVEhld3RRM2tY?= =?utf-8?B?WUEybTN1dWdXUlU5NjVRYXNSZThJQ3Z5bmd0QmxzOUpxUVpUbnhoM01zb1Jl?= =?utf-8?B?OE1Nd1N4a0VqSUNGU2lBcUFreW9MYVlSNEhLV3ZqZTcwc2p3UXhTT2RjTW5Z?= =?utf-8?B?S0tFM2NzdC8xU0tEaWZKazFtcFFodHo4Rlp1QmhrYU9EbTZhVkFzQkZMVFJ2?= =?utf-8?B?Q044NW1mOThSS2lJT0dkcWo2WHNRUGt0Zm44STBmYzdWbkdnYW5PbWpmWW1X?= =?utf-8?B?ZnU4cFJESG9RbktTTzVISktLUUlMOW5uZUYvcU41OXpndURvMktyQkVDUjh2?= =?utf-8?B?VGhvanBJQ2lrTU52WThhT3FUYm1FMzdpeVJlMU9JZ0dUNGtKQ2UrZVJocDdX?= =?utf-8?Q?4S5odT4MJFJDCeODSZ1bH86B7TRazixUO3VUfqO?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01D71754.00F559D0"
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: ddbb9249-2745-4467-ee77-08d8e562ccab
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2021 14:26:17.5454 (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: eJX7GN/1+g4//3B8MBFpxsP4np0WqTSICRcYPDHCMCHpC2hro3YcrG4lFUwAoHUzd1OXhDuj9LIwAVKRIFlvclEQInNpVVdKFrk5kiDddi4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0265
X-TM-SNTS-SMTP: AD4A50C3BD702EF80D8E760932DAB50891BA8EC4981A5ABFDE5F72F5894E212C2000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/BI_whkxqSgwxGNVPMgyJco6god4>
Subject: Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)
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: Fri, 12 Mar 2021 14:26:32 -0000

Hi Magnus,

Thanks. My comments refer to the ramp up phase of the measurement only, an important aspect I forgot to mention.

The sender has a  congestion budget Buffer_max[ms]@R[x] based on the last sending rate R[x] confirmed by FT[x] without congestion, when it starts to send by R[x+1] . 
- It takes RTT + FT, before that rate is adapted as a minimum. 
- As the smallest optimistic waiting time, after st[x+1] + Buffer_max[ms], there's no more queue at the receiver's access (if there's no competing traffic). 

That would help to determine a function when to earliest start the next st[x+2]. A behaviour definition specifying how to react after FT + RTT + Tolerance without any feedback may be as follows: 
- Repeat after Timeout by sending another st at rate R[x+1]. 
- Timeout = max ( st[x+1] + T_secure *  Buffer_max[ms] , FT + RTT + Tolerance ) with T_secure being an integer. "Tolerance" [s] on the order of some 10 [ms], I'd think.

Design doesn't have to be exactly like that, this is about the concept. Len, Al, please contact me if I missed an important part of the implementation (or if I here suggest to slow down the measurement to eternal).

Regards,

Rudiger (stick with "u", if the "ue" puzzles you)





-----Ursprüngliche Nachricht-----
Von: Magnus Westerlund <magnus.westerlund@ericsson.com> 
Gesendet: Freitag, 12. März 2021 14:11
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; iesg@ietf.org; acm@research.att.com
Betreff: RE: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)

Hi Reudiger,


> -----Original Message-----
> From: Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>
> Sent: den 11 mars 2021 17:32
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Cc: tpauly@apple.com; ianswett@google.com; draft-ietf-ippm-capacity-
> metric-method@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
> iesg@ietf.org; acm@research.att.com
> Subject: AW: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> metric-method-06: (with DISCUSS)
>
> Hi Magnus,
>
> Before going to discuss details some questions:
>
> Would it help to insert text that person initiating test is required to
> parametrize an access bandwidth to be validated?
> I'm asking, as the intent of the draft might not be to capture a completely
> unknown access bandwidth (but I think it doesn't say so explicitely yet).

I think that would help significantly.

>
> Do some of your comments address a concern that a test creates to much
> congestion during one feedback interval FT?
> That may stem from the idea, that we've exactly reached access bandwidth
> AB during FT and badly congest the access during FT+1 (I don't deny that 
> this
> is possible).

Yes, what I am worried in some cases is the amount of overshoot the load 
algorithm can cause. And that is not just one FT interval. The regulation loop 
is somewhere between one RTT and RTT + FT long without feedback losses, and 
with losses it could be as long as RTT + m*FT where m is the number of 
feedback interval until one makes it in the feedback. Thus the congestion 
volume in a static system becomes (R[x+1]-R[x])*(RTT + m*FT) and where RTT 
+m*FT is capped by the longest non responsive interval. So have much data this 
represents, i.e. how badly one affect the on path with overload. So this is 
highly dependent on the parameters which is why I think this is so hard to 
evaluate.

>
> If that's your concern, would an approach to limit the maximum congestion
> created before FT+1 is reached being bound to a limit
> Buffer_max[ms]@AB[Bit/s] based on the last captured congestion free
> bandwidth AB during FT?
> As an example, Buffer_max = 0,05 s if AB < 1 Gbit/s (smaller Buffer_max
> values may be applicable at higher rates). This would result in a formula
> determining the sending behaviour during st, rather than a table.

I am not certain if I understand this correctly. Are you proposing to have a 
congestion window for the increase, or the full transmission, so that it will 
throttle if it doesn't get feedback in a timely way?

I think the main problem here is that one need to analyze the parameter space 
for the limiter that are proposed and what impact the parameters have. That 
has been part of my problem analyzing the updated text.

Cheers

Magnus Westerlund