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

Martin Duke <martin.h.duke@gmail.com> Tue, 30 March 2021 00:30 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AAC3A26E4 for <alto@ietfa.amsl.com>; Mon, 29 Mar 2021 17:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bZeD4yyOZ6Nq for <alto@ietfa.amsl.com>; Mon, 29 Mar 2021 17:30:20 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 CD2ED3A26E3 for <alto@ietf.org>; Mon, 29 Mar 2021 17:30:20 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id z9so12753941ilb.4 for <alto@ietf.org>; Mon, 29 Mar 2021 17:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4eRmSBL8/cfIiyAOeYxVB/dWY2HV8+vxtHoqA6sUHtI=; b=lTTsSGzPmUTx1dlmL2sUhXBD2EKMSkoyUhcbSzZ8B3aUStiBNTaN9kb7q+rHrRxIoJ 5radZ8/DdHqwknBW62I+x0Ogu4GZeMJguU4Yw2TeiAAl323C4HRjA7Y3B0aEyfkmrJM+ lHsdVJ1tsoqx4+mzs/2Z1d4e9F0Mjn2FfOI/8m9EDnwlwC5oxM996cXmX6dDCKJgThpv dmes7D3Fy9eq40/UlNng3g+hWyI/OVtt/m1lBQ0Cd+pUnCl9xoI4X+0xB57g0jXc6AqW AWCHHfSQB6KLepIVVCt406NlSCvwI3QnUSNXhFcrhXHd8JOlysI0ijqJ/esNSw/jQzbz nyjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4eRmSBL8/cfIiyAOeYxVB/dWY2HV8+vxtHoqA6sUHtI=; b=AakD3rZrdmJzxSfZasQm03OXNGIM9LYBlZ9qjtYpugcR5m5QIzv+17J8AkGu68eEXt qhdaZe8RgKM3qLUdCABJJ+rGkcI8DLPbvc3i1y/+UaLpeVK1e324H1cEDaOEeAxwb7Xd 9Ppic6nu6C39L4caQPbpeTA0l+9sSdKGYsKMZ7jokST/0/QcUE8oPa7afZoMUR6iRNQc S96BWQ/g2/rC4oLisMdh8fkDgE29xEzqVwlMVOSUjoPmDAzOhLYkYTS8htNuqgBPicbJ 5DFimjI+EHIBu4jqbYuO04T7BQJJ0WROtrXeNjYyq4mqX2dQFK667HYbhjlEIa4vRRqA xueA==
X-Gm-Message-State: AOAM530W5g1XQClmltixSxkJVDyHjBhrJMbULvynnkNc8zmwrlBa1R6/ 0oMCl5YeyGbkX7/li6oX1ollJYewr2B/sSZORNZ2++lHY+A=
X-Google-Smtp-Source: ABdhPJwjXM6DQ2B0VHkCaTK0q5FcvZqf2J179LT7N1t9l5HFaMUhFBHLmWfSMW5BQvx5BsS8vn/QjsKd2fuxIq6vvis=
X-Received: by 2002:a92:c244:: with SMTP id k4mr5462962ilo.303.1617064218890; Mon, 29 Mar 2021 17:30:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxS5ZZ5Vnh__FD0eb4GfkR6YywoArnRp=JU4+z4FkeS8Kw@mail.gmail.com>
In-Reply-To: <CAM4esxS5ZZ5Vnh__FD0eb4GfkR6YywoArnRp=JU4+z4FkeS8Kw@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 29 Mar 2021 17:30:12 -0700
Message-ID: <CAM4esxROfSg6C6rUhPJV3_oozcCwhZwib3veO_bNtEZVAg+goQ@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Cc: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary="00000000000058955805beb61a5c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/QdbXB4Y8QRZNUgHiNwa3yYv3GlY>
Subject: Re: [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: Tue, 30 Mar 2021 00:30:25 -0000

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 <martin.h.duke@gmail.com>
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.
>
> COMMENTS:
> - 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 <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.
>
> 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] https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html
>