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

Martin Duke <martin.h.duke@gmail.com> Mon, 29 March 2021 18:34 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 63BD73A1E9D for <alto@ietfa.amsl.com>; Mon, 29 Mar 2021 11:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id G7rXngJp6Fze for <alto@ietfa.amsl.com>; Mon, 29 Mar 2021 11:34:02 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 CF5613A1EDC for <alto@ietf.org>; Mon, 29 Mar 2021 11:33:42 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id d2so12014497ilm.10 for <alto@ietf.org>; Mon, 29 Mar 2021 11:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6bEx5matNuvFZjN8uHxapTKYC+5s6VWF1ZsItHGcyNk=; b=LEilY4mhJximRcNHqNBVktdxdewX6puA+fk1/a95aohuVcucaokbAItBj3ho3n2Y0D dwccfEeZXqDfI05zqTN6u+lB0p/HNM5OXXb8J51ofxyofnibuuma6VdsNlT1veM99NBq +pEkd2BG957KExaWV3gsfIfpoKhyN+oUEwb3S0OHX0Q1IFvLKLY6JxcvgEliQ4y70hKQ Od60bRitjIVUqiMvFiMuYksqhQ/soATy0nJfliFrGp8B98oyvOsEhCbq9cKN22I7by1w STFNC6wQ72qgZbOGCk0Jzi6UjdGK3/YTzKpAsqXCSMpbnVKwUcLs64lieH2dJfEygtCN lX5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6bEx5matNuvFZjN8uHxapTKYC+5s6VWF1ZsItHGcyNk=; b=XejsU/udzhNV4RgOBD4ufsK2FEFGA/k1EAhxPP6GkQaW1FBZjya4VS5s2EguP1zfq5 e1QM+Jgji2jJtGdEnnAumjUpAL3pIRefvRhsxYPMLBarMwdITn8apF46hmkZBU++MKYm mDUT5OY/dpzXQ7f8EDEHXQs7ALliT67hXHdUwvMLzV0HNb18HTbYg1ZD7GeKtZWReTgW j5qYK6I8ezJGQc1PuJic2L6S61CAhGFJAsY8EJXehvGvS0JOl4abCwgRNNCsfdIje3iy i99E/C7P+VGRAZWtbIATkK445/wnCbvD+L9L9VY1qk2He7YscVwYpp6T2i4qFcWVsEaB Uk2A==
X-Gm-Message-State: AOAM533nk7MsS9MKzf5OD/htPr1osos+WAfgWzVmtJVzIEfZ42Hn2kAU WmB7PyGTb7IhDkIzucgFOjZcUSIpKO0rvjS5lsnjEB4sAeSV1Q==
X-Google-Smtp-Source: ABdhPJxBYtCAOeDuD+qXSyvG1XHxir9ds+5E8B6kGbGVEDaQznYwPK15T4Jv4enMJCEvrozy4wqhYlW4HLtIY2f+mpE=
X-Received: by 2002:a05:6e02:13e8:: with SMTP id w8mr21783402ilj.237.1617042821582; Mon, 29 Mar 2021 11:33:41 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 29 Mar 2021 11:33:35 -0700
Message-ID: <CAM4esxS5ZZ5Vnh__FD0eb4GfkR6YywoArnRp=JU4+z4FkeS8Kw@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Cc: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary="000000000000f7953805beb11e79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/Yh4Mgu4bDbz3H9GhB3-fbFBJCMw>
Subject: [alto] AD review of draft-ietf-alto-performance-metrics-15
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 18:34:12 -0000

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

- 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.

To address this issue, the only defined "routingcost" metric can be
   only "estimation".

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?

- 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:


On the other hand, to be able to use coarse-grained information such
   as routing system information (e.g., [RFC8571
<https://datatracker.ietf.org/doc/html/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.


  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

- Sec 6. s/is a highly sensitive/is highly sensitive


[1] https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html