From nobody Mon Apr 5 08:03:25 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 68FDC3A1CDA for ; Mon, 5 Apr 2021 08:03:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Yra1ktiAukVF for ; Mon, 5 Apr 2021 08:03:12 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 7E1043A1C27 for ; Mon, 5 Apr 2021 08:03:05 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id o15so6225590ilf.11 for ; Mon, 05 Apr 2021 08:03:05 -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=Mb+8mpQ8V/q2J1c5uTo3SRP2lTmRincbMcSGKQwemkA=; b=vNPzF0Pi+6Yxo+tHZMzPgidrAgQX/39LAiM9VtHiYi6g1nKemmqcnIesF3J5nfrUbl 3XIJcw4nfamTxv0kYmcNsu24kbMOIAgqQRu9+CZV1SB0VbaxaopirvZCVZAhxCva+pbK NKhMkiPSPnGLwLHIxLu/D+WGbcQ3Rtr7v0rfb3R7NWTrCKzVlx4HIrDqEAAstTVfNaEY I3M2Vsz3XqRP2n6CfQ3r+D5Z86Th0G/K1Wup2yi0UOMCgpY7KvvqlNSSkyt1TeY5F7fC WtHVyfQGjKlV4xQcCioUqX9cpYiWSpwEwY3IzXmYQm+HMnPIBKScAzagxddVxukhvFD5 y7Jw== 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=Mb+8mpQ8V/q2J1c5uTo3SRP2lTmRincbMcSGKQwemkA=; b=sTFwPFVViDweYWStfrvJAKLZkmJY659W+KoDIXSEhKnoM9IpwQg4VnY1YCYq3EXvtQ 17GpdjssbO1L31HRr3oR/bF1JoWuFKV9XA6NgUdA4hEiPuZLueVfJ8Mhzt1DbrAvIaNf ClmeQdvngsoF86r7eqB+TlNHQNjO5mZRLyfG7q5RjYLrQtu+3YuENQyVjjJ0SRgOGcZ7 0/cXeHj5OnpQaOrH3oDJhTns5ImiBNSpBqMitn7uWT+dZafA9CapwaYZe9jYn7ELRg3P m5mkc++z8crn6LT6W3NRlsPrzM0hPXgKku1xhfdq0a8GPnQPoMjs4r/pwJKeZNq70bbq u6ZQ== X-Gm-Message-State: AOAM530JRK0ZSyMSjnbosgxIguKeJpW76XDZqmqLbnzKEl3VB8EGH7sb VkdIGKiXf1TNisulPUZL0d87QNxdQrLpbN8m1qezWKXK X-Google-Smtp-Source: ABdhPJx5zTgwgFVLCAbCPCo13wqPmsrlnG87c1DFmN8Qg7bIhVKPp3FdpnZCpn4zKMvH/UTJartQ6ei8Xipv67p1H7g= X-Received: by 2002:a92:ca4b:: with SMTP id q11mr20210812ilo.272.1617634983973; Mon, 05 Apr 2021 08:03:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Mon, 5 Apr 2021 08:03:07 -0700 Message-ID: To: "Y. Richard Yang" Cc: IETF ALTO , Brian Trammell Content-Type: multipart/alternative; boundary="000000000000989eb505bf3afee4" 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: Mon, 05 Apr 2021 15:03:24 -0000 --000000000000989eb505bf3afee4 Content-Type: text/plain; charset="UTF-8" Hi Richard, Where needed, responses inline. On Fri, Apr 2, 2021 at 6:18 PM Y. Richard Yang wrote: > - 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? >> > > Good comment. This is a point which the WG indeed discussed multiple > times. The decision was that providing the source will give the server the > ability to indicate the source, and the client knows more about the > context. Some operational aspects are discussed in Sec. 5.1. There were > some discussions on potential normative specifications on the client-side > and/or the server-side, but the final decision is that ALTO provides > non-normative information. For example, the basic cost values are > non-normative, and only best-effort information. There can be out-of-ALTO > control loops, for example, business contracts, and the cost-source > supports indication of such information channel. > > The comment on clarifying whether the info will be for humans behind is a > great one. One use case setting discussed is that the link can provide > machine-readable specifications such as a machine-readable language > specifying the measurement parameters, but this is considered out of scope. > Will you recommend that we include more some more elaboration in the > operational considerations section (i.e., extending Sec. 5.1)? > If it were me, I'd put some of it in the intro and some motivation in 2.1, and maybe go through some miscellaneous considerations in 5. But that's less important that it be there somewhere. If the intent is that it be machine-readable, then there are several places where this standard is going to need more standardization (i.e. precise definition of text fields). But zooming out: I understand that the point is that "the client knows more about the context," which is pretty much what 5.1 says. But I don't understand if the "client" is the user or a user agent, and what either one would actually do with the information. Would the application execute a policy based on the source? Why would it use a latency that came from an sla, but not from measurement? etc. > >> - 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? >> > > It is target IP and the network. Here is some text in the current version > on the authentication and privacy aspects (Sec. 6): > "Indeed, TE > performance is a highly sensitive ISP information; therefore, sharing > TE metric values in numerical mode requires full mutual confidence > between the entities managing the ALTO server and the ALTO client. > ALTO servers will most likely distribute numerical TE performance to > ALTO clients under strict and formal mutual trust agreements. On the > other hand, ALTO clients must be cognizant on the risks attached to > such information that they would have acquired outside formal > conditions of mutual trust." > > Will this be OK? > That privacy information is alright, but exposing the details of third-party SLAs deserves special attention. But to follow up your answer: if the client has a better SLA than the target, this won't show up in the metrics at all? > > - 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. >> > > In the early WG discussion, they were considered separate, and then the > agreement was that import is a special case of estimation, with more > specific dependency tracking. Consider data provenance of how the ALTO data > are computed. Estimation means that the server does not want to indicate > the specific details, and the important gives a precise indication of the > exact protocols. > OK, I now understand that "import" implies a specific set of parameters. I can't understand what value this distinction has, but that just circles around to me not understanding the cost-source information at all. > - 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? > Good catch. The decision of the WG at the time was to use HTTP whenever possible. For example, the freshness is indicated by HTTP timestamp (see Sec. 5.2); by consistency, then, we should use HTTP Expires. We can add this. Agree? Sure. Martin --000000000000989eb505bf3afee4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

Where needed, responses inline.

On Fri, Apr 2, 2021 at 6:18 PM Y.= Richard Yang <yry@cs.yale.edu>= ; wrote:
- Sec 2.1. The cost-source model is conce= ptually sound, but the justification for it seems underexplained. What exac= tly 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 pre= sented to the humans behind ALTO clients?

=
Good comment. This is a point which the=C2=A0WG indeed discussed= multiple times. The decision was that providing the source will give the s= erver the ability to indicate the source, and the client knows more about t= he context. Some operational aspects are discussed in Sec. 5.1. There were = some discussions on potential normative specifications on the client-side a= nd/or the server-side, but the final decision is that ALTO provides non-nor= mative information. For example, the basic cost values are non-normative, a= nd only best-effort information. There can be out-of-ALTO control loops, fo= r example, business contracts, and the cost-source supports indication of s= uch information channel.

The comment on clarifying= whether the info will be for humans behind is a great one. One use case se= tting discussed is that the link can provide machine-readable specification= s such as a machine-readable language specifying the measurement parameters= , but this is considered out of scope. Will you recommend that we include m= ore some more elaboration in the operational considerations section (i.e., = extending Sec. 5.1)?

If i= t were me, I'd put some of it in the intro and some motivation in 2.1, = and maybe go through some miscellaneous considerations in 5. But that's= less important that it be there somewhere.

I= f the intent is that it be machine-readable, then there are several places = where this standard is going to need more standardization (i.e. precise def= inition of text fields).

But zooming out: I unders= tand that the point is that "the client knows more about the context,&= quot; which is pretty much what 5.1 says. But I don't understand if the= "client" is the user or a user agent, and what either one would = actually do with the information. Would the application execute a policy ba= sed on the source? Why would it use a latency that came from an sla, but no= t from measurement? etc.

=C2=A0

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

It is target IP and the network. Here is= some text in the current version
on the authentication and privacy asp= ects (Sec. 6):
"Indeed, TE
=C2=A0 =C2=A0performance is a highl= y sensitive ISP information; therefore, sharing
=C2=A0 =C2=A0TE metric v= alues in numerical mode requires full mutual confidence
=C2=A0 =C2=A0bet= ween the entities managing the ALTO server and the ALTO client.
=C2=A0 = =C2=A0ALTO servers will most likely distribute numerical TE performance to<= br>=C2=A0 =C2=A0ALTO clients under strict and formal mutual trust agreement= s.=C2=A0 On the
=C2=A0 =C2=A0other hand, ALTO clients must be cognizant = on the risks attached to
=C2=A0 =C2=A0such information that they would h= ave acquired outside formal
=C2=A0 =C2=A0conditions of mutual trust.&quo= t;
=C2=A0
Will this be OK?

That privacy information is alright, but exposing the detai= ls of third-party SLAs deserves special attention. But to follow up your an= swer: if the client has a better SLA than the target, this won't show u= p in the metrics at all?
=C2=A0
=
- Sec 2.1. Related to the above, the text suggests that any cost-sou= rce expressed as "import" could also be expressed as "estima= tion". Why would the server do this? The text should say, or perhaps i= t would be conceptually cleaner if "estimation" and "import&= quot; were mutually exclusive sources by definition.

In the early WG discussion, they were considered sepa= rate, and then the agreement was that import is a special case of estimatio= n,=C2=A0with more specific dependency tracking. Consider data provenance of= how the ALTO data are computed. Estimation means that the server does not = want to indicate the specific details, and the important gives a precise in= dication of the exact protocols.

OK, I now underst= and that "import" implies a specific set of parameters. I can'= ;t understand what value this distinction has, but that just circles around= to me not understanding the cost-source information at all.
=C2=A0
=C2=A0
- Sec = 5.4.1: "...the ALTO server may provide the client with the validity pe= riod of the exposed metric values."

Shouldn&#= 39;t there be a standard format for this? Or are you implying the use of co= st-calendar?

Good catch. The de= cision of the WG at the time was to use HTTP whenever possible. For example= , the freshness is indicated by HTTP timestamp (see Sec. 5.2); by consisten= cy, then, we should use HTTP Expires. We can add this. Agree?

Sure.

Martin=
--000000000000989eb505bf3afee4--