Hi Martin, Thanks for the quick feedback. Please see below.
On Mon, Apr 5, 2021 at 11:03 AM Martin Duke <martin.h.d...@gmail.com> wrote: > Hi Richard, > > Where needed, responses inline. > > On Fri, Apr 2, 2021 at 6:18 PM Y. Richard Yang <y...@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 mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
