Subject: [alto] WG chair review of draft-ietf-alto-deployments-14

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Apr 2016 13:06:30 -0500

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-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 28 Apr 2016 20:18:02 +0200

Vijay,
all,

Vijay: thanks for the detailed review!

On Thu, Apr 28, 2016 at 01:06:30PM -0500, Vijay K. Gurbani wrote:
>   I find that a bit obtuse, and that may be just me.  What does it
> mean for an
>   resource directory in ALTO is the canonical IRD defined in
> rfc7285. So what

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

>   guidance to a "resource directory"?  I can see what it means when
> the ALTO
>   intrepret giving guidance to a resource directory.  Perhaps you
> meant to say
> - S2.1.2, first paragraph: Saying that "host that runs the
> application", while
>   Here, what context does the phrase "using the ALTO guidance"
> impart? Does
>   to a resource consumer different than the one provided to a
> client? Where
> - S2.2.1, sixth paragraph, item 2: s/clients, e.g., after/clients
> only after/
> 
>   advantage is not that the "operational information" stays within
> the client,
>   but rather the client's "query string" remains private.  The
> server is not
>   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
> - S3.1.1, first paragraph: Insofar as you want to make a distinction
> on an NSP
>   connectivity and routing in the network they manage, they must
> depend on an
> - S3.1.3, last paragraph: s/ALTO is not/That said, it must be
> understood that
>   s/values, and the ALTO client will not be informed about the
> nature of the
>   information./values.
> 
>   bandwidth is a constrained resource, normal wireless (IEEE 802.11)
> is not as
>   text that makes it costly for peers in PID 3 to get content from
> PID 1, but
> - S3.6.1, Figure 15: What would be good is if the link weights in
> this figure
> - S4.1.2, first paragraph: s/outside the networks of the
> ISPs/external to the
>   ISPs/
> 
>   client embedded in the tracker sends only local peers to the
> querying peer.
>   preferred by the ALTO server responsible for the querying peer.
> The peers
>   initial selection of candidates, but does not consider peers
> learned through
>   Same paragraph: s/by talking to the ISP's tracker./by talking to
> the ISP's
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Apr 2016 13:22:03 -0500

> We will add a clarification that the RFC 5693 definition is meant.

OK, I had forgotten about the use of that early meaning!

Yes, that will work; probably just say that "We use the term Resource
Directory as defined in RFC5693, which defines it as an entity that is
logically separate from the resource consumer and that assists the
resource consumer to identify a set of resource providers.  This use
of the term is different than the usage ascribed to the term Information
Resource Directory defined in RFC7286.  For the remainder of this
document, the term Resource Directory is to be interpreted as defined in
RFC5693."

That will do it.

> The other issues (below) seem to be mostly editorial stuff - we will

Sounds good.  Thanks a lot.  As soon as I see a revision, I can send the
document to IESG.

Cheers,

- vijay