Vijay, all, Vijay: thanks for the detailed review!
On Thu, Apr 28, 2016 at 01:06:30PM -0500, Vijay K. Gurbani wrote: > 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. In this document, in particular in Sec. 4.2.2, "ressource directory" is used as an abstract term for BitTorrent trackers and similar entities, i.e., something in the "signaling plane" or the like, which is not the endpoint of the bulk data transmissions that we we want to optimize. The usage of this term is consistent with RFC 5693 (ALTO problem statement), which defines: Resource Directory: An entity that is logically separate from the resource consumer and that assists the resource consumer to identify a set of resource providers. Some P2P applications refer to the resource directory as a P2P tracker. This term coined in the very early days of ALTO is not to be confused Information Resource Directory (IRD) defined in RFC 7285 (ALTO protocol). We will add a clarification that the RFC 5693 definition is meant. The other issues (below) seem to be mostly editorial stuff - we will take care of them. thanks, Sebastian > - 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
