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

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sat, 20 Jun 2015 20:31:39 +0000

Hi Wendy,

Many thanks for this very comprehensive and very useful review.

Sebastian and me have worked on a new version that should address all raised issues. Below is a list what has been changed (see the lines marked with "=>"). The list only mentions those points that were not straightforward to change; the other modifications have just been applied as suggested.

I've just posted the new version -12: https://www.ietf.org/internet-drafts/draft-ietf-alto-deployments-12.txt or https://tools.ietf.org/html/draft-ietf-alto-deployments-12

The complete diff can be found at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-deployments-12

Please let us know if there should be any further thoughts or comments.

Best regards

Michael

***Review response ***

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

=> Section 2.2.2 has been entirely rewritten. See -12 for the new wording.

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

=> I've added at the end of section 4.2.2:  "In principle, a combined approach could also be possible. For instance, a tracker could use a coarse-grained  "global" ALTO server to find the peers in the general  vicinity of the requesting peer, while peers could use  "local" ALTO servers for a more fine-grained guidance. Yet,  there is no known deployment experience for such a combined approach."

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

=> Updating any out-dated references will be handled by the RFC editor. Quite a number of those references have been there when I started editing the document. Others have been added based on mailing list requests. And clearly some of the drafts include relevant content even if it is not clear if there will be an RFC (e.g., draft-lee-alto-chinatelecom-trial). I updated some of the outdated references, but I hesitate to remove references.

---------
Minor suggestions:
---------

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

=> I have changed the routing of the non-preferred lines, but I have not completely changed the layout. I think the key point in this figure is that traffic for the non-preferred connection goes from ISP 1 to ISP X and then to ISP 2. Rerouting the non-preferred lines outside ISP 1 and ISP 2 would make it more difficult to see that the non-preferred connections traverse several ISPs. As additional explanation, I have also added the label "inter-network traffic" inside the figure.

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

=> Yes, both sections are similar. But the motivation is different. 3.1.2 is mostly about reducing peering cost, whereas 3.1.3 deals with mitigating bottlenecks, i.e., traffic engineering. I've added a sentence to each section to better highlight the different motivation. I also collapsed the two figures into one.

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

=> I have reworded the sentences to better distinguish address and prefix:

   "For instance one IP address IP1 out of a given CIDR prefix can be
   assigned to a VDSL access line (e.g., 2 MBit/s uplink) while
   another IP address IP2 within the same given CIDR prefix is
   assigned to a slow ADSL line (e.g., 128 kbit/s uplink). These IP
   addresses may be assigned on a first come first served basis, i.e.,
   a single IP address out of the same CIDR prefix can change its
   associated costs quite fast."

---------
Nits:
---------

---------
page 49, 3d para, "an over-the-top CDN":
    "Over-the-top" means extravagant, ridiculously overdone, etc. Is that really what you mean?

=> "over-the-top" has a special meaning in this context, see e.g. http://en.wikipedia.org/wiki/Over-the-top_content. I've put the term into quotes to better illustrate this meaning.

---------
Other nits not requested in review:
---------

* Changed the order of Sections in 3.3, moving the Section "General Limitations" to the front; the actual text has not been changed

* s/resource selection/resource provider selection/

* Various smaller editorial bugfixes

From: alto [mailto:[email-masked]] On Behalf Of Wendy Roome
Sent: Thursday, May 28, 2015 9:23 PM
To: [email-masked]
Subject: [alto] Review of draft-ietf-alto-deployments-11

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