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

"MORTON, ALFRED C (AL)" <acm@research.att.com> Wed, 31 March 2021 23:37 UTC

Return-Path: <acm@research.att.com>
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 8D9143A3B84; Wed, 31 Mar 2021 16:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Wh1l91RjjjUC; Wed, 31 Mar 2021 16:37:41 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 1C4543A310D; Wed, 31 Mar 2021 16:37:40 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 12VNXeut022578; Wed, 31 Mar 2021 19:37:39 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049458.ppops.net-00191d01. with ESMTP id 37n2d10fdq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Mar 2021 19:37:39 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 12VNbckj085861; Wed, 31 Mar 2021 18:37:38 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 12VNbY7v085771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Mar 2021 18:37:35 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 22598403A433; Wed, 31 Mar 2021 23:37:34 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30496.vci.att.com (Service) with ESMTP id F1B65403A421; Wed, 31 Mar 2021 23:37:33 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 12VNbXN0126622; Wed, 31 Mar 2021 18:37:33 -0500
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 12VNbOcO125858; Wed, 31 Mar 2021 18:37:25 -0500
Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-blue.research.att.com (Postfix) with ESMTP id 7F85A10A191B; Wed, 31 Mar 2021 19:37:23 -0400 (EDT)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0513.000; Wed, 31 Mar 2021 19:37:46 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
CC: "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt
Thread-Index: AQHXJOMHlm9sjtq8v0uvrodRIOhLraqcfcAAgAAgCgCAAV5yAIAAHfYAgABTGACAAEsagA==
Date: Wed, 31 Mar 2021 23:37:46 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0147CD4BB8@njmtexg5.research.att.com>
References: <161705348048.17388.9380614999436689902@ietfa.amsl.com> <HE1PR0702MB3772E8BA15BFF01315E139A8957D9@HE1PR0702MB3772.eurprd07.prod.outlook.com> <FRYP281MB01127BBC2A94F40783044DFE9C7D9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <201af4d37914dfc0a87204b82c6db3c236acea6d.camel@ericsson.com> <FRYP281MB011208657C5A83AA34F137829C7C9@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM> <ae21c673c1f86ab3e4907c0f74e04e5b12d5a0f0.camel@ericsson.com>
In-Reply-To: <ae21c673c1f86ab3e4907c0f74e04e5b12d5a0f0.camel@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.148.42.167]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-GUID: hNyYW97-7q-wGz96i1JbF6ebhffu3nLW
X-Proofpoint-ORIG-GUID: hNyYW97-7q-wGz96i1JbF6ebhffu3nLW
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-31_11:2021-03-31, 2021-03-31 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 phishscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103310000 definitions=main-2103310162
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ofVlegV5B3e1B3zMNHl_BrbenpI>
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 23:37:46 -0000

Hi Magnus, Rüdiger, and all,

Grabbing a couple of recent comments for reply:

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: Wednesday, March 31, 2021 10:28 AM
<snip>
> Yes, so I think ECN is definitely something that can wait for future
> improvements. I was simply trying to be as clear as possible that from an
> endpoint you don't have that many basic indicators of congestions.
[acm] 
OK, we don't mention ECN right now.

> 
> So I am primarily concerned that this one has the right description for what we
> expect it to do. From my perspective I have no issue with this being published
> with a clear limited applicability and clear indication of what it is expected
> to do. For the intention I am fine with you authors reword it to something
> similar that is more consistent with the existing text. I just want it to be
> clear that due to the nature of the intent to measure capacity it may push
> existing elastic traffic out of the way in the probing to determine
> maximum capacity.
[acm] 
Right.

In Version 08, we have this statement in the Scope/Applicability section regarding the 
algorithm:

   The load rate adjustment algorithm's goal is to determine the Maximum
   IP-Layer Capacity in the context of an infrequent, diagnostic, short
   term measurement.  It is RECOMMENDED to discontinue non-measurement
   traffic that shares a subscriber's dedicated resources while testing.

We can express the limitations more clearly in the first sentence, 
and augment the second sentence as follows:

The load rate adjustment algorithm's scope is limited to helping determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short term measurement. It is RECOMMENDED to discontinue non-measurement traffic that shares a subscriber's dedicated resources while testing: measurements may not be accurate and throughput of competing elastic traffic may be greatly reduced.

> 
> Cheers
> 
> Magnus
> 
> On Wed, 2021-03-31 at 09:30 +0000, Ruediger.Geib@telekom.de wrote:
> > Hi Magnus,
> >
...
> > 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
...
> >
> > Hi Ruediger,
> >
...
> > >
> > > [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.
> >
[acm] 
Len has run some tests using the running code (version 4.5 at that time) with 
10 competing TCP (iperf) flows using CUBIC CCA on a 500Mbps rate-limited  access.
This is a rather extreme scenario for competing traffic. 

With the default load rate adjustment parameters, it wasn't possible to starve all 
the elastic traffic in a test using 10 second duration. However, an algorithm 
modification to retain fast rate increases following congestion produced more 
accurate test results during a 10 second test. This modification has shown some value
in other extreme circumstances, such as inter-continental testing [see Ref Y.Sup60].

Hope this helps,
Al



> > Cheers
> >
> > Magnus