Re: [alto] Tsvart early review of draft-ietf-alto-performance-metrics-03

"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <> Fri, 13 April 2018 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E6FE12426E; Fri, 13 Apr 2018 08:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjNjLMpkn3Qk; Fri, 13 Apr 2018 08:27:49 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe02::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 966961241F5; Fri, 13 Apr 2018 08:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pOIpQK+FnX0Fa3Opjh28/+cbPymtyNRTg6lTbn8FxVA=; b=HSRRrcqcy4dCrDkXpvgwLoXPthNgjEcMIhpSZgH0aKYio7Nc6vjsUHZhyX7WUZu297vaz5Mvxh8TX1X7yusD+O9y68vhULAwrdUe85/RCHHorhFO3L09FQJN8aiNWudostBKTRd8iw3IzD9HmhLpPCRGq4a43PvtD/rV07TNTMQ=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Fri, 13 Apr 2018 15:27:46 +0000
Received: from ([fe80::697c:b3ae:9f6e:6a9d]) by ([fe80::697c:b3ae:9f6e:6a9d%2]) with mapi id 15.20.0675.004; Fri, 13 Apr 2018 15:27:46 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <>
To: "Brian Trammell (IETF)" <>, TSV Area Review Team <>
CC: "" <>, "" <>, IETF Discussion Mailing List <>
Thread-Topic: Tsvart early review of draft-ietf-alto-performance-metrics-03
Thread-Index: AQHT0CDHS9TnENZH+UqfQNjoFml72KP9jgwAgAFIcKA=
Date: Fri, 13 Apr 2018 15:27:45 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1315; 7:bh8uqsiKmbLzcUDIK6aZLmHlIYdVKqBbVhKbpJjUI4gTah5pMNCrfPhDBHru9X4NxX8/HJ0PcCQSz5+VloqNJgpQFGeH5b/tQPJv6vxJ4kXao3OkIRVlv+4dH8/LoIPRF7jFNFUEcUlSW+txUDipqby4ckaG1T2CBAWzA5HI1nPbUjNxUSqBcbzdE1YD9gQiTMQ/OyHQGjxnHa5McJdySqTBsd1pOBiE8FVvRKVdG7hJAEMsV4puOyHrHHiokEQZ
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:AM4PR07MB1315;
x-ms-traffictypediagnostic: AM4PR07MB1315:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231232)(11241501184)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB1315; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1315;
x-forefront-prvs: 0641678E68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(39380400002)(376002)(366004)(199004)(13464003)(189003)(53936002)(6436002)(6246003)(105586002)(97736004)(25786009)(2906002)(11346002)(55016002)(26005)(186003)(102836004)(3660700001)(3846002)(3280700002)(76176011)(9686003)(66066001)(446003)(486006)(6506007)(59450400001)(53546011)(476003)(7696005)(6116002)(106356001)(99286004)(68736007)(5660300001)(8676002)(7736002)(8936002)(305945005)(81166006)(74316002)(81156014)(86362001)(110136005)(229853002)(2900100001)(478600001)(4326008)(5250100002)(33656002)(54906003)(316002)(14454004)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1315;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 8TalKgLh9nPIMssqi+ttJlvJcm2I++MZEgcT8L29TTpbglPYw/xJMcLrNGafHUq2qUxiQKsFDBdpKmierMu5YNPNaRiGHB5BA/u+jOJWHto7kM2dE6C0/ysXnlkA+sKOHglJz2GB1SWnrxL0GI01N0tTHPdryjMh4G9dU1ZMB406b+DCHm90hV08kM8T9hJD
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 5ee1357b-97ca-41d7-7a75-08d5a1531baa
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ee1357b-97ca-41d7-7a75-08d5a1531baa
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 15:27:46.0127 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1315
Archived-At: <>
Subject: Re: [alto] Tsvart early review of draft-ietf-alto-performance-metrics-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Apr 2018 15:27:52 -0000

Hi Brian,

Thanks so much for your thorough review. We'll get back with answers and update proposals asap.

-----Original Message-----
From: Brian Trammell (IETF) [] 
Sent: Thursday, April 12, 2018 9:48 PM
To: TSV Area Review Team <>
Cc:;; IETF Discussion Mailing List <>
Subject: Re: Tsvart early review of draft-ietf-alto-performance-metrics-03

On further review, I have an additional question about the metrics specified in the document:

Max reservable (sec 8.1) and residue (sec 8.2) bandwidth seem to be fairly straightforward to calculate in a stable manner, as they are essentially matters of router configuration, but I'm a little concerned about the temporal aspects of available and utilized bandwidth. On any link containing congestion controlled traffic not otherwise limited (e.g. by a tunnel reservation), even a small number of active bulk transfer flows will cause the utilized bandwidth to max out on short timescales: you get an almost uselessly noisy metric.

I presume, since this metric is taken straight from an IS-IS standards track RFC, that this doesn't happen in practice, i.e. that the temporal denominator is large enough that it averages these smaller peaks out. It'd be nice if the document named a timescale though.

I'm also a little dubious that instantaneous bandwidth is a useful cost metric for a system like ALTO, because even on sane timescales the delay imparted by the system makes  the information hard to act on in a useful way, unless the link is a large enough aggregate that the bandwidth doesn't change much over time.



> On 9 Apr 2018, at 18:35, Brian Trammell <> wrote:
> Reviewer: Brian Trammell
> Review result: On the Right Track
> I've performed a (late, apologies) early TSV-ART review of 
> draft-ietf-alto-performance-metrics-03.
> The set of metrics chosen by the document seem broadly useful and 
> sane, and the integration into ALTO makes sense. However, there are a 
> few issues with the details.
> Periodic One Way Delay, RTT, and PDV are defined in terms of section 
> 8, section 4, and section 5, respectively, of 
> draft-ietf-ippm-initial-registry, which specify active measurement 
> test methodologies at layer 4 for one-way and round-trip delay using 
> UDP packets. This does not seem it can be measured directly using the 
> routing  technologies the authors have identified as their source of 
> information. Is the intention that dedicated active measurement 
> hardware be used to measure delay using UDP packets, or should these metrics reference [RFC2679] and [RFC2681] and leave the methodology undefined, instead?
> The examples for these don't make much sense: the units are expressed 
> in seconds, but Internet-scale delays are generally millisecond-scale, 
> and the examples given contain only integers. Similarly, packet loss 
> rate is given in percentile, but there are wide variations in 
> usability between a path with 0%, 1%, and 2% packet loss. Is this simply an issue with the examples?
> The hop count metric is underspecified: are these IP-experienced hops 
> at layer 3, as can be measured by traceroute?
> Nit: section 2.1 refers to [OSPF-TE], [ISIS-TE], [BGP-LS] and 
> [BGP-PM], but these are not listed as such as references in the 
> references section. Please use consistent reference labels.
> Thanks, cheers,
> Brian