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

"Y. Richard Yang" <> Thu, 08 April 2021 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 844803A19BC for <>; Thu, 8 Apr 2021 13:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fmWZgCfd_N57 for <>; Thu, 8 Apr 2021 13:04:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 794693A19BA for <>; Thu, 8 Apr 2021 13:04:29 -0700 (PDT)
Received: by with SMTP id u10so3754479lju.7 for <>; Thu, 08 Apr 2021 13:04:29 -0700 (PDT)
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=bhJC35/UfSAdLhjSEGcnbePtMyJ9F36ZuXQ/+nkaoEk=; b=HpFD7Buz/unBWKpMXaPZZRAV0lC7Zf0WZtgDds6cHjARBjCP0tXvw9+u//kOqZ2hvr rowZwQuKbjsYHa+4Ydqefvl/eabuSXEDiHNc7mQhYwUfn70QzyrNC8ApwH2mS0L/kl2Z sgvNcdc5sRDP5BZ74luxD4atjB6mQqpJrOmrSyxJ4IDCU4tIUnC9u6UW4ALJNPQXcKo1 EadtPfBLfrsTDRlEg7gRFohtKdTnBJ+1Qr1CF65kkPsE0XKXRcvYrvZS8LPoay92iJ4Q 48ojXlJMArIuPNV0lC3AuaR8g3j6UL7Jpu3p3T8X8/nqymEFQ4fIq7+TMoKzxP3QW+K4 wcZQ==
X-Gm-Message-State: AOAM531B7Dz5nwyd3gZqqaQIX7fkIdxK+vlKY+3NrauJwvcGZ5rIAFot GZOvGtdqR7BUHCahb6VJLK12vzVWZwsbmLvUQ4w=
X-Google-Smtp-Source: ABdhPJzvhnyTrSFOgNQClFt9gfi6tRKVJSlBhiGlFJ21pHP1HmihTixbVGI9X8bGerffqog07M3Wr1VZlAw7UzBwGYE=
X-Received: by 2002:a2e:9a97:: with SMTP id p23mr7032356lji.375.1617912267282; Thu, 08 Apr 2021 13:04:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "Y. Richard Yang" <>
Date: Thu, 08 Apr 2021 16:04:16 -0400
Message-ID: <>
To: Martin Duke <>
Cc: IETF ALTO <>, Brian Trammell <>
Content-Type: multipart/alternative; boundary="000000000000f81d2605bf7b8d68"
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: Thu, 08 Apr 2021 20:04:35 -0000

Hi Martin,

Thanks for the quick feedback. Please see below.

On Mon, Apr 5, 2021 at 11:03 AM Martin Duke <> wrote:

> 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.
> Thanks for the note. We are adding a few sentences in 5.

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

Some of the authors discussed the issue and feel that going down the path
of making the content machine-readable, in a systematic way, adds
substantial complexity.

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

This is a good comment. Here is an example ( that motivated some
early discussions. In this example, AT&T post both target (aka sla. should
we change the name from sla to service-level-target?) and actual
measurements. In this sense, ALTO can be considered as a standard way of
providing and update the information. Both target and actual values can be
useful. Make sense?

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

Now I see that I need to clarify. The metric is end-to-end, from src IP to
dst (target) IP. Does this clarify? I can add a sentence to clarify this.

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

I see. Let me try to clarify slightly differently. import means that the
ALTO server can provide a precise source of information using specific
parameters, and estimate is that it comes from a black-box (the server does
not reveal). Thinking about it a bit more, we can go down the path of
specifying a precise format (rfc/section just as ippm) when specifying
import. Will this be a direction that you want to go?

>> - 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.
Thanks a ton!


> Martin