Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

Martin Duke <> Tue, 30 March 2021 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EF053A1DA6 for <>; Tue, 30 Mar 2021 11:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3lk06WvjsCEO for <>; Tue, 30 Mar 2021 11:23:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 030AC3A1DA5 for <>; Tue, 30 Mar 2021 11:23:53 -0700 (PDT)
Received: by with SMTP id j16so6418191ilq.13 for <>; Tue, 30 Mar 2021 11:23:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i+C0eswIFaQoaYAdgo7DslHF99RpM2FdCKKPERgHOGs=; b=HJm8zeMz9iHMYalqBW3Xoa0eGljtgHzDfqM9nmjJaaZ2o+bLXh93+insoSzVFreypb WgyLr1Q0p10JwSikeiQNLI/nHYrM/Y5++apThxM2eqYcR0QSrk8H1Wol4IlFZTqBXRaU kd2bB2neQFBwH9XLQdvrrlIYIzF/jHnrzrASk9pZdyPUxHabJmbzjM4MY+fdnEpfIe9g lBg13iVNgPdpbyR3Irn7i5mi+btjl/DxRCxVdb6LLmIC9lxxq1t76ejEhpUDRZ09CqL1 KtM1XTk8C83KAH3kljZUUv5JGJyPdmM0gmuR/WjEX/mu31UUMj5J5/jp2Xx/DCRDhL57 rUiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i+C0eswIFaQoaYAdgo7DslHF99RpM2FdCKKPERgHOGs=; b=K+dqKBJ/BUTCG6olgQ2YvKoBcKT7tvsfN39gZyyQ8R3gFhIpRtXHD8UkUnlkWzgJ5E rSx0CxOn6ER/4XP2Y3igU2Ps02G3FtyK6V/NTuSe2Cdges57+Bpgl6oZvQ7IASlkF0q+ na9uU9D+D7YaCtCE4YOa4a4huROAeB7sDP/lfzjpQVqMkCaa+xAZpvDkF1ye9dw8LmB8 V59KTvikksccTgXruXEexpwsnhR3hk5vBePzqm97YbohqFUvIzRVkoxw3vFY+tT0DyYR V1/9p+dEfJcH5hep05KTvNjeIrL3YJ2JS7M+s02lzep6QpLxrw0r/JOfMvH0eVvmkQXs CpAg==
X-Gm-Message-State: AOAM530ebM6PvuIkyMeYb1TVNTwjc9A6+ScJNcn9C4EO3DNeMW9uwOR5 0y5v4cY44eKJL9JyjxACWeUYsLLtY8O3q5jxKG2rZpg2UkHDRA==
X-Google-Smtp-Source: ABdhPJw787wlzjbK8/DdJPK+SmBPaBE7wcyDsF9wiyrHXg8aKjgckG2c5y2KySaI0ikaayLx8rw4rV+z5iY5eNVAA94=
X-Received: by 2002:a92:c244:: with SMTP id k4mr8599254ilo.303.1617128631971; Tue, 30 Mar 2021 11:23:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Tue, 30 Mar 2021 11:23:48 -0700
Message-ID: <>
Cc: Brian Trammell <>
Content-Type: multipart/alternative; boundary="000000000000aa32c805bec51926"
Archived-At: <>
Subject: Re: [alto] AD review of draft-ietf-alto-performance-metrics-15
X-Mailman-Version: 2.1.29
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: Tue, 30 Mar 2021 18:23:59 -0000

Sorry for the fragmented review, but there are a couple of more issues:

- The authors should do a review of all lower-case occurrences of must,
should, may, and recommended. At least a few of them should be capitalized
to indicate normative requirements.

- IMO, from a quick review,  I-D.ietf-ippm-initial-registry as written is
normative and should be listed as such. However, I think it would be better
to simply refer to the actual registry (
rather than tie it to the initial entries.

On Mon, Mar 29, 2021 at 5:30 PM Martin Duke <> wrote:

> One small correction: I'm jumping the gun on the author policy; 6 is
> probably OK for now.
> On Mon, Mar 29, 2021 at 11:33 AM Martin Duke <>
> wrote:
>> Hello authors,
>> Thank you very much for writing this draft. It is clearly a useful
>> extension to ALTO and is quite clearly written, even to someone who is not
>> a practitioner. I have numerous comments/questions and a few nits.
>> These points are all invitations to discussion, rather than commands
>> about what to change, as I've missed much of the WG deliberations that led
>> to this text.
>> - There are six authors. Having more than 5 editors/authors listed on the
>> front page requires strong justification and chair/AD approval. See the RFC
>> Editor statement [1]. You are encouraged to designate a few editors for the
>> front page and list as many authors as desired at the end.
>> - Sec 2.1. The cost-source model is conceptually sound, but the
>> justification for it seems underexplained. What exactly is a client going
>> to do with this information? What different behaviors would a client
>> execute if the context was e.g. "sla" instead of "nominal?" To the extent
>> the parameters are not machine readable, like links to webpages, are we
>> really expecting this information to be presented to the humans behind ALTO
>> clients?
>> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
>> this refer to an SLA the ALTO client has with the network? Between the
>> target IP and the network? Or something else? If the first, does this link
>> to client authentication in some way? If the second, what are the privacy
>> implications of exposing these SLAs?
>> - Sec 2.1. Related to the above, the text suggests that any cost-source
>> expressed as "import" could also be expressed as "estimation". Why would
>> the server do this? The text should say, or perhaps it would be
>> conceptually cleaner if "estimation" and "import" were mutually exclusive
>> sources by definition.
>> - Sec 3. I would prefer it if the parameters field in each of these
>> definitions was a bit more strict. This relates to my confusion about
>> machine-readable vs. human readable data; if this is meant to be
>> machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
>> out that the IGP protocols should be in a format with the RFC number, for
>> instance. If it's to be human readable for a purpose I don't understand,
>> then these looser definitions are probably OK.
>> - Sec 3.4 Unlike the other metrics, I have no idea what a client is to do
>> with the hop count metric, since clients don't care about hop count. Hops
>> only affect users through delay and loss rate, which is present in other
>> metrics. Is the intent here to provide a proxy for delay when direct delay
>> information is not available? If so, we should say so.
>> - Sec 5.3. I suggest a reword.
>> OLD:
>> To address this issue, the only defined "routingcost" metric can be
>>    only "estimation".
>> NEW:
>> To address this issue, if the "routingcost" metric contains a
>> cost-context field, it MUST be "estimation."
>> What should clients do if it's not "estimation?" Can they use it or
>> reject the metric
>> as malformed?
>> - Sec 5.4.1: "...the ALTO server may provide the client with the validity
>> period of the exposed metric values."
>> Shouldn't there be a standard format for this? Or are you implying the
>> use of cost-calendar?
>> - Sec 5.4.2: I don't understand what this section is saying. Can the
>> server provide new metrics not in the spec? Or is it saying that the server
>> can take singletons about link one-way delays and compose path one-way and
>> two-way delays, for example?
>> NITS:
>> - Sec 1. An initial sentence introducing ALTO at the beginning would be
>> helpful, e.g.
>> "ALTO [RFC 7285] provides a means for client to identify the most
>> efficient information source when multiple copies of such information
>> exist, by quering path information from an HTTP server."
>> - Sec 2. The second paragraph is a little hard to read. Suggestion:
>> OLD:
>> On the other hand, to be able to use coarse-grained information such
>>    as routing system information (e.g., [RFC8571 <>]), which may not
>>    provide fine-grained information such as (iii) Method of Measurement
>>    or Calculation and (vi) Measurement Timing, this document provides
>>    context information to indicate the source of information and hence
>>    available metric details.
>> NEW:
>>   This document specifies context information to indicate the metric
>> source, which can allow clients to obtain fine-grained information like
>> (ii) Method of Measurement or Calculation and (vi) Measurement Timing."
>> - Sec 2.1 In Fig. 1, please expand "NBI" on first use.
>> - Sec 3.1.3 Expand "PID" on first use.
>> - Sec 3.1.4 s/recommended/RECOMMENDED
>> - Sec 3.4 s/metric hopcount/hopcount metric
>> - Sec 4.1.3 would this be correct: s/give the throughput/give the maximum
>> throughput
>> - Sec 6. s/is a highly sensitive/is highly sensitive
>> Thanks
>> Martin
>> [1]