Re: [alto] AD review of draft-ietf-alto-performance-metrics-15
"Y. Richard Yang" <yry@cs.yale.edu> Thu, 08 April 2021 20:04 UTC
Return-Path: <yang.r.yang@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 844803A19BC for <alto@ietfa.amsl.com>; Thu, 8 Apr 2021 13:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmWZgCfd_N57 for <alto@ietfa.amsl.com>; Thu, 8 Apr 2021 13:04:29 -0700 (PDT)
Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (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 794693A19BA for <alto@ietf.org>; Thu, 8 Apr 2021 13:04:29 -0700 (PDT)
Received: by mail-lj1-f182.google.com with SMTP id u10so3754479lju.7 for <alto@ietf.org>; Thu, 08 Apr 2021 13:04:29 -0700 (PDT)
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=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: <CAM4esxS5ZZ5Vnh__FD0eb4GfkR6YywoArnRp=JU4+z4FkeS8Kw@mail.gmail.com> <CANUuoLpKD=ZdxGodB=NvmeebCn17g8tmca22VuVPrSBuCDQ2Bw@mail.gmail.com> <CAM4esxRtqyJZFhU2Jw4HJeF-WeNzci-dH1VnWPSKejXE8cEUWA@mail.gmail.com>
In-Reply-To: <CAM4esxRtqyJZFhU2Jw4HJeF-WeNzci-dH1VnWPSKejXE8cEUWA@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Thu, 08 Apr 2021 16:04:16 -0400
Message-ID: <CANUuoLqFV0XCMbua8b_swn-sLnAouF0+9DTrbE6USDHLEcmR5g@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: IETF ALTO <alto@ietf.org>, Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary="000000000000f81d2605bf7b8d68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/58MWLRwhKz9Ft9dB01YZPozwAok>
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: 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 <martin.h.duke@gmail.com> wrote: > 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 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 ( https://ipnetwork.bgtmo.ip.att.net/pws/averages.html) 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. > Yes. > 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! Richard > Martin >
- [alto] AD review of draft-ietf-alto-performance-m… Martin Duke
- Re: [alto] AD review of draft-ietf-alto-performan… Martin Duke
- Re: [alto] AD review of draft-ietf-alto-performan… Martin Duke
- Re: [alto] AD review of draft-ietf-alto-performan… Y. Richard Yang
- Re: [alto] AD review of draft-ietf-alto-performan… Y. Richard Yang
- Re: [alto] AD review of draft-ietf-alto-performan… Martin Duke
- Re: [alto] AD review of draft-ietf-alto-performan… Y. Richard Yang
- Re: [alto] AD review of draft-ietf-alto-performan… Martin Duke
- Re: [alto] AD review of draft-ietf-alto-performan… Qin Wu
- Re: [alto] AD review of draft-ietf-alto-performan… Martin Duke
- Re: [alto] AD review of draft-ietf-alto-performan… Qin Wu