Folks,
Vijay Gurbani asked me to do a detailed review of the alto-deployments
draft before we complete Last Call.
My review is long, so I attached it as a text file. Hopefully the list
server will save that file somewhere and provide a link when it forwards
this. If not, I will put the file on my server.
Overall, I found several minor issues, plus numerous nits. Fortunately
they should be easy to fix.
I only found two major issues. First, Section 2.2.2 is very confusing, and
I suggest rewriting a few paragraphs (details in the review file).
Second, it references a number of expired drafts, some going back to 2010.
They should be updated to reference the latest versions. And if an expired
draft does not have a newer version, consider deleting the reference.
- Wendy Roome
Review of ALTO Deployment Considerations, draft-ietf-alto-deployments-11, March
2, 2015
Reviewer: Wendy Roome, May 27, 2015.
Major issues:
---------
{2.2.2}:
I found this section to be hard to understand, and in particular I think the
term "preferences" is EXTREMELY confusing. That sounds like a client can keep
preference lists on the ALTO server. I don't think the ALTO RFC uses
"preferences" at all.
First, I suggest changing "preferences" to "costs" or "information" or "data"
(I assume that's what the authors mean by "preferences").
Second, the wording of items #1 & #2 is very confusing. I think the point of
this section is that a client can either get the cost data for all endpoints at
once and lookup specific costs whenever it wants (#1), or else a client can
request data for specific endpoints when it needs them (#2). #1 means the
server reveals a lot to the client, and the client reveals nothing to the
server; #2 means the client reveals a lot to the server, and the server reveals
limited data to the client.
At least I think that's the point. I suggest rewriting this section -- the
numbered paragraphs in particular -- to make it clearer.
---------
{4.2.2}:
I am surprised you did not consider a combination approach, where the tracker
and the peers BOTH use ALTO. In this case, the tracker would use a
coarse-grained "global" ALTO server, while the peers would use their "local"
ALTO server. Thus the tracker would use ALTO to find the peers in the general
vicinity of the requesting peer.
For example, if the peer is in Japan, the tracker would return peers in Asia,
while if the peer is in Paris, the tracker would return peers in Europe. The
requesting peer in Paris would use its local ALTO server to determine which
peers are in France and which are in (say) Hungary.
---------
{Informative References}:
This section references a number of drafts that are more than a year old. By
now, those have either become RFCs, been superseded by newer versions, or else
have been moved to the cosmic bit bucket. In any case, references to expired
drafts are not very informative, and they make this document look out-of-date.
I suggest the authors update the document to reference the latest versions, and
drop references to drafts that have expired.
---------
Minor suggestions:
---------
---------
{2.1.2}, Figure 2: It took me a few moments to figure out that the unlabeled
boxes on the right were hosts containing an ALTO client & an application. It
would help if the top box were expanded to something like
+--------------+
| Application |
|--------+ |
=====| ALTO | |***
| Client | |
+--------+-----+
*
*
*
---------
{2.1.2}, Figure 3: It is similarly confusing. How about expanding the "Resource
directory" box to something like
+---------------+
| | **
|--------+ |**
=====| ALTO | |********
| Client | |**
+--------+------+ **
Resource
Directory
---------
{2.2.1}, 2d paragraph: "An ALTO service includes four types of entities: ..."
I think that conflicts with the definition of "ALTO Service" in 2.1.1.
Specifically, 2.2.1 says the ALTO client & resource consumer are part of the
ALTO Service, while 2.1.1 says the ALTO Service gives guidance to the resource
consumer, which implies to me that the consumer is not part of the ALTO Service.
My opinion is that the "ALTO Service" includes the ALTO server and the
information source, but does not include ALTO clients or resource consumers,
because a client can use several different, unrelated ALTO servers. Hence the
transitive closure could include in every ALTO server, client and consumer in
the network.
I think the easiest way to resolve the inconsistency is to change the first
line to something vague, like "An ALTO deployment involves four kinds of
entities:"
---------
page 8, 4th para: "The size of the user group": It's not really the size, is
it? Seems like that section is more concerned with the composition, or
trustworthiness, of the user group.
---------
{2.2.3}, Figure 4: The ==== lines from the "University ALTO Server" to the "ISP
ALTO Server" and "Peer1" to "PeerN" are very hard to follow. I suggest you
move the "University ALTO" box a few spaces to the right, and re-route the ====
lines around the top and bottom, so the graph is planar. And then you can use
----- and | and + instead of ====.
---------
{3.1.1}, 3d para: "This traffic engineering for overlay formed by the
application can have different objectives": What do overlays have to do with
this? I think that sentence can be written as "This traffic engineering can
have different objectives". If not -- if "for overlay" is important -- please
explain why.
---------
{3.1.1}, para #3, "Network off-loading": "it is likely that hosts in fixed
networks should avoid retrieving data from hosts in mobile networks, and hosts
in mobile networks should prefer retrieval of data from hosts in
fixed networks." Can't that be simplified to "it is likely that hosts should
prefer retrieving data from hosts in fixed networks, and avoid retrieving data
from mobile hosts." ?
---------
{3.1.2}, Figure 5: It would help if you could make the graph planar. Eg, have
the "non-preferred" line go from Host 1 (not 2) to Host 4, move Host 1 up, and
Host 4 down. Then re-route the non-preferred lines from Host 1 to ISP X to Host
4 above ISP 1 and below ISP 2.
---------
{3.1.3}: Does this section really add anything new? It seems like this example
is isomorphic to {3.1.2}. Just change "ISP 1" and "ISP 2" to "Net 1" and "Net
2", and change "ISP X" to "bottleneck inter-island connection".
---------
{3.1.4}, Figure 8: Shouldn't the legend have ###### for "preferred
connections"? And there is a stray "-" in the upper "######" line.
---------
page 25, last para, "one IP addresses IP11 out of a IP prefix IP1": I don't
understand that. One possibility is that "IP11" is a specific address and "IP1"
is a CIDR prefix. If that is the case, I suggest replacing "IP1" with a
specific CIDR, such as 1.2.0.0/16, replace "IP11" with a specific address, such
as 1.2.3.4, and change "addresses" to "address". And change IP12 in the next
sentence to 1.2.3.5. But if that is not what you meant, please clarify the
sentence.
---------
page 55, 4th para, "based on the endpoint property service": I think you mean
endpoint COST service.
---------
{7.4}, Faking ALTO Guidance:
Here's another example, if you want to add it: Fake guidance could give
unrealistically low costs to devices in an ISP's mobile network, thus
encouraging other devices to contact them, thereby degrading the ISP's mobile
network and causing customer dissatisfaction.
---------
Nits:
---------
---------
{1}, last para, 3d line, "... imposed load to the ALTO server, or from whom the
queries ...": change "or" to "and/or".
---------
page 8, second para: "can be differentiated e.g. according to": I think the
"e.g." is grammatically incorrect without additional punctuation. And even with
punctuation, it still seems odd. How about just dropping the "e.g."?
---------
page 8, 4th para: "also decide to only offer guidance to": Normally I don't
mind boldly splitting an infinitive, but that one goes too far. I suggest
changing that to "also decide to offer guidance only to".
---------
page 8, next to last para: "there is no requirement that an ALTO server is
deployed and operated by ISPs.": s/ISPs/an ISP/.
---------
{3.1.1}, first para: "The Internet provides network connectivity e.g.": Add a
"," after "connectivity". Or else enclose the e.g. clause in parentheses:
(e.g., by access networks, such as ....., etc.).
---------
{3.1.1}, 3d para: "influencing application resource selections.":
s/selections/selection/
---------
{3.1.3}, 1st para: "inside a single network or, e.g., one AS." Change to
"inside a single network (e.g., one AS)."
---------
{3.1.5}: "Applications can often run own measurements":
s/run own/run their own/
---------
page 18, first para: "the ALTO topology does not contain any details": I
suggest you change "contain" to "reveal".
---------
page 21, top paragraph: "allow a dynamic computation of cost between groups": I
think that would read better as "allow THE dynamic computation of COSTS between
groups". Capitals only to emphasize the changes, of course.
---------
page 23, 2nd para, "Other metrics representing an abstract cost, e.g., ....":
That sentence contains two "e.g."s. Reword it.
---------
page 23, 4th para, "with high probability the actual performance values differs
from": Change to "differs" to "differ". Or better yet, "will differ".
---------
page 23, next to last para, "the candidate endpoints throttles the bandwidth":
Change "endpoints" to "endpoint".
---------
page 23, last para, "the candidate endpoints will throttle the data it sends to
us": Change "endpoints" to "endpoint" and "us" to "the client".
---------
{3.3.1}, 1st para, "into Provider-defined Identifier (PID) that group one or
multiple endpoints": Change "Identifier (PID)" to "Identifiers (PIDs)" and
"multiple" to "more".
---------
{3.3.1}, 1st para, "between the various PIDs is stored": s/is/are/
---------
{3.3.1}, 2nd para, "static for a longer period of time": s/longer/long/
---------
page 26, 2nd para, "cost map and possibly also network maps can change". Change
"map" to "maps".
---------
{3.3.2}, first para, "ALTO clients can ask guidance for specific IP addresses
to the ALTO server,": I suggest you rewrite that as "ALTO clients can ask the
ALTO server for guidance for specific IP addresses,".
---------
{3.3.2}, 2nd para, "However, asking for IP addresses, asking with long lists of
IP addresses, and asking quite frequently may overload the ALTO server.": I
suggest you rewrite that as "However frequent requests, particularly with long
lists of IP addresses, may overload the ALTO server."
---------
page 32, first para:
"cost of link" => "cost of a link"
"clients of inner ISP's network" => "clients of the inner ISP's network"
"clients of outer ISP's network" => "clients of the outer ISP's network"
"a host with ALTO client" => "a host with an ALTO client"
---------
{3.5.3}, first para:
"fixed network my focus" => "fixed network may focus"
"fixed network as far as possible" => "fixed network as much as possible"
---------
page 36, 2nd para,
"requiring data resource from" => "requiring data resources from"
---------
page 36, last para,
"the relations between": I think that reads better as "the relationships
between"
---------
{3.6}, first para,
"ALTO service in real network" => "ALTO service in a real network"
"with further network conditions" => "with additional network conditions"
---------
{3.6}, 2nd para,
"an ALTO-like service influence" => "an ALTO-like service can influence"
---------
{4.1.1}, first para,
"applications have been the" => "applications were the"
---------
{4.1.1}, 2nd para,
"build without or with use" => "built with or without use"
"a list of candidate resource providers, which" => "a list of candidates
which"
"different options how ALTO can" => "different options for how ALTO can"
---------
page 39, first para,
"In the scenario depicted" => "The scenario depicted"
"peers), giving thus the peers" => "peers), thus giving the peers"
"e.g. offered by their ISP, as described in [RFC7286]."
=> "(e.g., offered by their ISP, as described in [RFC7286])."
---------
page 40, first para,
"is different to the resource consumer." => "is different from the
resource consumer."
I suggest you re-write the rest of that paragraph as:
Initially, the tracker has to discover the handling ALTO server for each new
peer [RFC7286] [I-D.kiesel-alto-xdom-disc]. 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.
---------
page 40, last para before {4.2} heading:
"to let ISPâs to deploy" => "to let ISPs deploy"
"the client has no chance to get" => "the client cannot get"
"other than talking to" => "other than by talking to"
---------
{4.2.1}, first para,
"Different to that," => "Alternatively,"
---------
{5.1.1, first para, "as explained e.g. in" => "as explained in"
---------
page 47, last para,
"(ECS): When an end user request a given content,"
=> "(ECS). When an end user requests a given content,'
---------
page 48, first para,
"the list of content targets addresses" => "the addresses"
("content targets" is incorrect; it should be either "content target"
or "content targets'". But the meaning is clear from context, so anything more
than "the addresses" is noise)
---------
{5.2.2}, 2nd para,
"have information which end user IP subnets" => "have information about
which end user IP subnets"
---------
{5.2.2}, 3d para,
"with the decision which upstream source" => "with the decision about
which upstream source"
---------
page 49, 1st para,
"ALTO can be uses as interface [I-D.seedorf-cdni-request-routing-alto], in
particular for footprint and capabilities advertisement interface."
I think you mean
"ALTO can be used as an interface [I-D.seedorf-cdni-request-routing-alto],
in particular for footprint and capabilities advertisement."
---------
page 49, 3d para, "an over-the-top CDN":
"Over-the-top" means extravagant, ridiculously overdone, etc. Is that
really what you mean?
---------
page 49, 3d para, "backbone": drop the quotes.
---------
page 49, 4th para, "ALTO server ranks" => "An ALTO server ranks"
---------
page 49, 5th para,
"backbone partitioning will have to take into account by"
=> "backbone partitioning will have to be taken into account by"
---------
{6.1}, 1st para, "to communicate among them" => "to communicate among
themselves"
---------
{6.1}, 2nd para,
"Similar like in the general Internet" => "As in the general Internet"
"in VPNs environments" => "in VPN environments"
---------
{6.1}, 3d para: Rewrite the last sentence as
"Network topology information could be useful for placement of replicas as
well as for the scheduling of transfers."
---------
{6.1}, 4th para: "could run own data centers" => "could run its own data
centers"
---------
page 50, last para,
"Similar like in other ALTO use cases," => "Similar to other ALTO use
cases,"
---------
page 51, 1st para: "Since VPNs run often in" => "Since VPNs often run in"
---------
page 51, 2nd para: "an application will not be have connectivity"
=> "an application will not have connectivity"
---------
{6.2}, 1st para:
"proposed for a cooperations between" => "proposed for cooperation
between"
---------
Figure 23: Move the vertical line from "ISP 1 network" to "ISP 2 network"
several spaces to the right, to line up with the "+" marks.
---------
page 53, 1st para: "architecture of a potential P2P cache deployments"
=> "architecture of potential P2P cache deployments"
---------
{7.1}, 2nd para, "This somewhat intransparent situation"
"intransparent" is rarely used; "nontransparent" or "opaque" are the more
widely used alternatives. But I don't really see how that situation is opaque.
How about just replacing that phrase with "This situation"?
---------
{7.1}, 3d para:
"This is different to more controlled environments"
=> "This differs from more controlled environments"
---------
page 55, 3d para: "map based apporach" => "map based approach"
---------
Various places, ALTO Server vs ALTO server: Most of the text references use
"ALTO server", but there are a few "Server" instances that I think (for
consistency) should be lower case. Specifically,
Bottom of page 18: "An ALTO Server can also use other ..."
{3.4.1}, first para: "deployment of an ALTO Server may shift network"
{5.2.1}. 2nd para: "Once the request router obtained from the ALTO Server
..."
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
