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