Re: [ippm] Estimating IP layer capacity in draft-morton-ippm-capacity-metric-method

"MORTON, ALFRED C (AL)" <acm@research.att.com> Thu, 21 November 2019 07: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 169BE120815 for <ippm@ietfa.amsl.com>; Wed, 20 Nov 2019 23:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 p3KugPzkBFGA for <ippm@ietfa.amsl.com>; Wed, 20 Nov 2019 23:37:40 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 71587120255 for <ippm@ietf.org>; Wed, 20 Nov 2019 23:37:40 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xAL7ZODt015075; Thu, 21 Nov 2019 02:37:40 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049297.ppops.net-00191d01. with ESMTP id 2wd7ytbfb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 02:37:39 -0500
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 xAL7bcS0090023; Thu, 21 Nov 2019 01:37:38 -0600
Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xAL7bXHG089956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Nov 2019 01:37:33 -0600
Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id 3201D4005C2B; Thu, 21 Nov 2019 07:37:33 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30495.vci.att.com (Service) with ESMTP id 09C674005C29; Thu, 21 Nov 2019 07:37:33 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xAL7bWcV018218; Thu, 21 Nov 2019 01:37:32 -0600
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xAL7bRu8017746; Thu, 21 Nov 2019 01:37:27 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id ABE1FF0955; Thu, 21 Nov 2019 02:37:26 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Thu, 21 Nov 2019 02:37:26 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: Nieminen Klaus <Klaus.Nieminen@traficom.fi>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: Estimating IP layer capacity in draft-morton-ippm-capacity-metric-method
Thread-Index: AdWelppHADagnxxBRFmMXcLQzn7bkQBo9D5g
Date: Thu, 21 Nov 2019 07:37:05 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6EFCA58@njmtexg5.research.att.com>
References: <3971320832ee43dcbc3af4ee86e8b708@traficom.fi>
In-Reply-To: <3971320832ee43dcbc3af4ee86e8b708@traficom.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.132.255]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 phishscore=0 adultscore=0 spamscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210067
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/iiWJKO2k7FKSRKnDRhETHYNRtfk>
Subject: Re: [ippm] Estimating IP layer capacity in draft-morton-ippm-capacity-metric-method
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: Thu, 21 Nov 2019 07:37:42 -0000

Hi Klaus,

Thanks for your method and implementation questions.
We've discussed this in-person, and a short
summary follows below.

Al

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Nieminen Klaus
> Sent: Tuesday, November 19, 2019 12:33 AM
> To: ippm@ietf.org
> Subject: [ippm] Estimating IP layer capacity in draft-morton-ippm-
> capacity-metric-method
> 
> Hi,
> 
> I have one question on how much this metric restricts the measurement
> setup and e.g. can WebTransport be used in the measurement? As I
> understand this, if we are running the measurement at the application
> layer, we can measure application layer (e.g. HTTP/3) payload. This again
> means that we can only estimate the IP layer capacity as we do not have
> full information about the header sizes or potential retransmissions. I
> think we can estimate this with a certain error margin, but I was not sure
> if this is fine according to the metric.
[acm] 
It should be possible to obtain information from the host OS about the 
lower layers in use, such as v4 or v6, ETH or WiFi or Cellular LTE/5G.
But there may be cases where some work is necessary to pass system info
to the measurement application.

We need to use UDP for transport: error distributions with TCP are seen 
to be time and technology dependent. TCP's congestion-awareness based on
packet loss, window sizes, reordering, and duplicate packets make for an
underestimate, which is often significant and highly variable. Many test
results illustrating the error have been shared.

> 
> I have not studied this much further, but started to think this question
> when I read the part 5.3.  Metric Definitions that talks a case where the
> packet size is known and of fixed size, but is this really the case?
> Should there be more flexibility to also be able to estimate the IP layer
> capacity from the application layer measurement results? I think this
> should be clarified.
[acm] 
It's very much easier to do the layer conversions when we use UDP, with
fixed and known sizes, but there are cases where we might want to 
allow a portion of two sizes.  
@@@@ update text with this idea.
> 
> And if we think this should be possible, at least I think it would be
> useful to add how this estimation can be done to the metric itself as the
> target is to harmonize the specified metric and this is not specified, it
> may lead discrepancies between implementations.
[acm] 

@@@@ Layer conversion:
The authors have lots of details on these calculations, having done
many of them during lab and field tests and tool development.

> 
> Any thoughts on this?
> 
> Best, Klaus
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=CkKxfs26ipBr8nSSaJUfs8BBGtBje
> wOBqsS1FBX9cJk&s=xST_c50cCPP49eav2yMJWG-osdzvmay-ZZ02x6M5X8s&e=