From nobody Mon Mar 29 17:30:27 2021 Return-Path: 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 ; 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 ; 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 ; Mon, 29 Mar 2021 17:30:20 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id z9so12753941ilb.4 for ; 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: In-Reply-To: From: Martin Duke Date: Mon, 29 Mar 2021 17:30:12 -0700 Message-ID: To: IETF ALTO Cc: Brian Trammell Content-Type: multipart/alternative; boundary="00000000000058955805beb61a5c" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 00:30:25 -0000 --00000000000058955805beb61a5c Content-Type: text/plain; charset="UTF-8" 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. > > 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 ]), 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 > --00000000000058955805beb61a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One small correction: I'm jumping the gun on the autho= r policy; 6 is probably OK for now.

On Mon, Mar 29, 2021 at 11:33 AM Mar= tin 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 si= x authors. Having more than 5 editors/authors listed on the front page requ= ires strong justification and chair/AD approval. See the RFC Editor stateme= nt [1]. You are encouraged to designate a few editors for the front page an= d list as many authors as desired at the end.

- Se= c 2.1. The cost-source model is conceptually sound, but the justification f= or 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 clien= ts?

- Sec 2.1 I am confused about the meaning of t= he "sla" cost-source. Does this refer to an SLA the ALTO client h= as with the network? Between the target IP and the network? Or something el= se? If the first, does this link to client authentication in some way? If t= he second, what are the privacy implications of exposing these SLAs?
<= div>
- 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 &= quot;import" were mutually exclusive sources by definition.
=
- Sec 3. I would prefer it if the parameters field in each o= f these definitions was a bit more strict. This relates to my confusion abo= ut 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, the= n these looser definitions are probably OK.

- = Sec 3.4 Unlike the other metrics, I have no idea what a client is to do wit= h 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 me= trics. Is the intent here to provide a proxy for delay when direct delay in= formation 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 c= an be
=C2=A0 =C2=A0only "estimation".

NEW:
To address this issue, if the "routingcost" metri= c contains a cost-context field, it MUST be "estimation."

What should clients do if it's not "estimation?&= quot; Can they use it or reject the metric
as malformed?

- Sec 5.4.1: "...the ALTO server may provide the clie= nt with the validity period of the exposed metric values."
<= br>
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 n= ew metrics not in the spec? Or is it saying that the server can take single= tons about link one-way delays and compose path one-way and two-way delays,= for example?

NITS:
- Sec 1. An init= ial sentence introducing ALTO at the beginning would be helpful, e.g.
=

"ALTO [RFC 7285] provides a means for client to id= entify the most efficient information source when multiple copies of such i= nformation exist, by quering path information from an HTTP server."

- Sec 2. The second paragraph is a little hard to re= ad. 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 t=
he metric
source, which can allow clients to obtain fine-grained informa=
tion 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.<= /div>

- 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 ma= ximum throughput

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

Thanks
Martin

--00000000000058955805beb61a5c--