Subject: [alto] Review of draft-ietf-alto-deployments-11

From: Wendy Roome <[email-masked]>
Date: Thu, 28 May 2015 15:22:32 -0400

Apparently the list server thought my text file was too vanilla.  Here is
the text of my review:

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
..."

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 May 2015 16:29:18 -0500

On 05/28/2015 02:22 PM, Wendy Roome wrote:
> Apparently the list server thought my text file was too vanilla.  Here
> is the text of my review:
>
> Review of ALTO Deployment Considerations,
> draft-ietf-alto-deployments-11, March 2, 2015
>
[...]

Wendy: Excellent, thanks for the review!

Authors of deployment considerations: Please prepare a revision so Jan
and I can move the document ahead.  We will be preparing a shepherd's
writeup soon.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
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