Folks: I have (as a WG chair) reviewed the latest deployment draft,
draft-ietf-alto-deployments-14.  My review is below.  I have also shared
the proto-writeup of this document on the list [1].

[1] https://www.ietf.org/mail-archive/web/alto/current/msg03039.html

Please go through my review and decide which of the comments you want to
incorporate in version -15.  As soon as I see version -15 on the list, I
will move the document out of the WG.

Thanks for all of your hard work.  This is an excellent document that is
full of pertinent information related to ALTO.

The comments below are in document order form, starting from Section 1.

General comments:

- There is this idea that an ALTO client is running in a resource directory.
I find that a bit obtuse, and that may be just me. What does it mean for an
  ALTO client to run in a resource directory?  As far as I can tell, a
resource directory in ALTO is the canonical IRD defined in rfc7285. So what does it mean to say that an ALTO client is running in a resource directory?

  Either I am missing something or we need to define what running in a
  resource directory means for this document.

- S1: My suggestion would be to rewrite the first sentence as follows for
  conciseness and brevity:
"Many Internet applications access resources that are available as several
  equivalent replicas on different hosts."

- S1, paragraph 1: s/a desired resource./the desired resource./

- S1, paragraph 2: s/from whom the queries are performed./who initiaties the
  queries./

- S2.1.1, paragraph 1: s/In the following/Below/

- S2.1.1, bullet item 1: What does it mean to say that an ALTO service gives
guidance to a "resource directory"? I can see what it means when the ALTO
  service gives guidance to a "resource consumer", but not sure how to
intrepret giving guidance to a resource directory. Perhaps you meant to say that the ALTO services "gives guidance to a resource consumer and provides a
  resource directory about ..."?

The last context I have of a "resource directory" is that of the definition
  of an IRD in the ALTO protocol.  Have things changed since then?

- S2.1.1, bullet 2: s/to the queries to the/to satisfy the queries about a
  particular/

- S2.1.1, bullet 3: I am still confused about embedding the ALTO client in
  "the resource directory".  What does this mean?

- S2.1.1, last paragraph: s/An ALTO service may be/A particular ALTO service
  may be/

- S2.1.1, last paragraph: s/one ALTO servers./one ALTO server./

- S2.1.2, first paragraph: s/at various entities in a network deployment./at
  various places in a deployed network./

- S2.1.2, first paragraph: You say that "The first differentiation...",
  however, I don't see a "second differentiation".  Thus, the qualifier
  "first" is redundant.  Also see next comment.

- S2.1.2, first paragraph: Saying that "host that runs the application", while
  technically correct, allows a lot of ambiguity.  Which "application"?
  Perhaps better to rewrite the first paragraph as:
  The ALTO server and ALTO clients can be situated at various places in a
  deployed network.  An ALTO client may be located on the actual host that
  executes an application that requires ALTO (Figure 2); alternatively, the
ALTO client could be located on a resource directory as shown in Figure 3.

- S2.2.1, second paragraph: "4. Resource consumer (using the ALTO guidance)". Here, what context does the phrase "using the ALTO guidance" impart? Does not the ALTO client also uses the ALTO guidance? Is the guidance provided to a resource consumer different than the one provided to a client? Where
  have you made the distinction between an ALTO client and a resource
  consumer?  Later on in S3.2.2 you make a distinction by qualifyin an
application as a resource consumer; perhaps you can make this distinction up
  front.

- S2.2.1, fifth paragraph: s/As explained in [RFC5693], from this follows
  that at least three different kinds of entities can operate an ALTO
  server:/At least three different autonomous entities can operate an
  ALTO server [RFC5693]:/

- S2.2.1, fifth paragraph, item 2: s/Topology information could also be
  collected by entities separate from network operators but that may
  either have collected network information or have arrangements/Topology
  information can also be collected by entities distinct than the network
  operator who use public sources to collect network information or have
  arrangements/

- S2.2.1, sixth paragraph, item 1: s/network, or not/network.

- S2.2.1, sixth paragraph, item 1: s/a lot of constraints,/a number of
  constraints/

- S2.2.1, sixth paragraph, item 2: s/clients, e.g., after/clients only after/

- S.2.2.1, last paragraph: s/if no ALTO servers can be found/in the absence of
  any ALTO server,/

- S2.2.2, first paragraph, item 1: s/the client does not have to reveal/the
  server does not have to reveal/

- S2.2.2, first paragraph, item 2: s/can be realized/is realized/

- S2.2.2, third paragraph: "For the client, approach 1...".  Here, the
advantage is not that the "operational information" stays within the client, but rather the client's "query string" remains private. The server is not
  privy to the computation that the client is doing on the maps.

  So, I would suggest that the text be reworded as follows:
  s/all operational information stays within the client and is not revealed
  to the provider of the server./the queries the client initiates remain
  private to the client./

- S2.2.3, item 1: What is an example of "metric" (single "metric" guidance)?
  You may want to provide one.

- S2.2.3, item 1: s/REST- ful protocol/REST-ful protocol/

- S2.2.3, item 1: "an ALTO service can use known methods to balance the load
between different server instances ..." Here, load balancing is not done by the ALTO service as much as it is done by the ALTO server provider's network
  infrastructure.  Plus, what are these "known methods", some sort of a
  reference may help.

Perhaps this substitution text may help (replaces the last two sentences of
  item 1):
Load balancing in ALTO can be accomplished by known methods, including, but
  not limited to assigned unique REST-ful URIs to different service
  instances.

- S2.2.3, item 2: s/determine what provided information may indeed be
  useful./interpret the received information accordingly./

- S2.2.3, last paragraph: s/not towards NREN/not destined towards NREN/

- S3.1.1, first paragraph: Insofar as you want to make a distinction on an NSP
  and an ISP, the distinction should be that while NSPs provide network
connectivity and routing in the network they manage, they must depend on an
  ISP to connect them to the Internet.  Thus, an ISP may be an NSP but the
reverse is not true. I don't know whether you want to make this distinction
  or not, but thought I'd point it out.

- S3.1.1, item 3: s/smaller link bandwidth/low link bandwidth/

- S3.1.2, last paragraph: s/possible or even not be desirable/possible, or
  even desirable/

- S3.1.3, last paragraph: s/ALTO is not/That said, it must be understood that
  ALTO is not a general purpose/

- S3.1.4, first paragraph: s/may have the desire/may seek to/

  Same paragraph: s/own//

  Same paragraph: I would suggest rewriting the last sentence ("One reason
  ... of the Internet") as follows:
  One reason could be that the wireless network or the mobile hosts are not
engineered for direct peer-to-peer communications between mobile hosts, and
  therefore, it makes sense for peers to fetch content from remote peers in
  other parts of the Internet.

- S3.1.4, last paragraph: s/it may require that the ALTO server can
  distinguish/it may require the ALTO server to distinguish/

  Same sentence: s/, e.g.,//

- S3.1.5, first paragraph: s/, e.g.,//

- S3.2.1, first paragraph: s/ALTO, such as network and cost maps./ALTO to
  create network and cost maps./

- S3.2.1, last paragrah: s/abstracted view/abstract view/

- S3.2.2, first paragraph: s/abstracted view/abstract view/

- S3.2.2, first paragraph: s/present endpoints/endpoints/

- S3.2.2, below Figure 8, second bullet item: s/link state/link-state/
  (for consistency with how it is written in the preceeding text).

- S3.2.4, second paragraph: s/interpreted, e.g., whether/interpreted, i.e.,
  whether/

- S3.2.4, first bullet under "Distance-related rating criteria:"
s/values, and the ALTO client will not be informed about the nature of the
  information./values.

  Next sentence: s/this kind of information/topological distances/

- S3.2.4, last bullet of the section: s/bandwidth, e.g., of cable/bandwidth of
  cable/

- S3.3.3, second paragraph: s/a larger number/a large number/

- S3.5.1, paragraph 3, right above Figure 9: s/define: C1<C2/define C1<C2/

- S3.5.3, first paragraph: The key point here is that the cellular wireless
bandwidth is a constrained resource, normal wireless (IEEE 802.11) is not as
  much constrained as the cellular data network.  My suggestion would be to
  simply s/wireless bandwidth/cellular wireless bandwidth/

- S3.5.3, Figure 13: For the sake of completeness and symmetry, you should
  specify the costs for the links that joins (PID 3, PID 1), as well as the
text that makes it costly for peers in PID 3 to get content from PID 1, but
  not as costly to get content from PID 2.

- S3.6.1, paragraph right above Figure 15: s/boundaries.  It is
  running/boundaries; it is running/

- S3.6.1, Figure 15: What would be good is if the link weights in this figure
  were also reflected in Figure 14.  That way, later on when one is
interpreting the hopcount cost map (Figure 20), it is easy to see that the
  path weight between R1->R3->R4->R9 is 40.

- S3.6.4, third paragraph: s/certain pair the corresponding field/certain
  pair, the corresponding field/

- S3.6.4, last paragraph: s/"default" PID is sort of virtual PID/"default" PID
  is, in a sense, a virtual PID/

- S4.1.1, first paragraph: s/in the application/of the user/
  (Rationale: QoE is a subjective metric, an application is not a sentient
  thing that can measure QoE.  A human user is.)

  Same paragraph: s/is assumed to be the/is an/

- S4.1.1, second paragraph: s/without or with/with or without/

- S4.1.1, last paragraph: s/usually only/only/

  Same paragraph: s/is supposed to yield/should yield/

- S4.1.2, first paragraph: s/outside the networks of the ISPs/external to the
  ISPs/

- S4.1.2, third paragraph: s/BitTorent/BitTorrent/

- S4.1.2, discussion under Figure 22: The key point here is that the ALTO
client embedded in the tracker sends only local peers to the querying peer.
  The ALTO client figures out who these local peers are by discovering and
  communicating with the ALTO server responsible for the querying peer.

  This needs to be stated more explicitly, otherwise the message is lost to
someone who is not a practitioner in this field. I would suggest re-writing
  the paragraph under Figure 22 as follows:

An alternative deployment scenario for a tracker-based system is depicted in
  Figure 22.  When the tracker receives a request from a querying peer, it
  first discovers the ALTO server responsible for the querying peer.  This
discovery can be done using [RFC7286] [I-D.kiesel-alto-xdom-disc]. The ALTO
  client subsequently sends to the querying peer only those peers that are
preferred by the ALTO server responsible for the querying peer. The peers
  do not query the ALTO servers themselves.  This gives the peers a better
initial selection of candidates, but does not consider peers learned through
  direct peer-to-peer knowledge exchange.

- S4.1.2, paragraph under Figure 23: s/server, other than/server other than/

Same paragraph: s/by talking to the ISP's tracker./by talking to the ISP's
  tracker, which in turn communicates with the ALTO server using the ALTO
  protocol./

- S7.1, second paragraph: s/is not always clear/may not be apparent/

- S7.4, in the "Sorting" paragraph: s/change to sorting/change the sorting/

  Same section: You should finish the section by stating that: "Faking ALTO
  guidance, while a real possibility, can be mitigated by using an
authenticated and encrypted transport between the server and the requesting peer. In terms of the ALTO protocol, the https:// scheme provides such an
  encrypted and authenticated stream."

- S9: s/discusses/has enumerated and discussed/

<End of review>

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to