Hi Michael, Hans and all, As promised, here is my feedback to sections 1 to 3.4 included. I tried to separate "Nits only" and "nits + comments". In a first step, I am sending the review as an attachment.
Again, thanks a lot for the work, this text is very well structured, clear and interesting. Some parts need a bit of clarifications and also, some re-phrasing to highlight the advantages of ALTO Services and providing incentives to use them is suggested here and there. Thanks, Sabine >>-----Message d'origine----- >>De : alto [mailto:[email protected]] De la part de EXT Randriamasy, >>Sabine (Nokia - FR) >>Envoyé : vendredi 5 février 2016 18:56 >>À : Gurbani, Vijay (Nokia - US); IETF ALTO >>Objet : Re: [alto] State of the WG >> >> >>Hi Michael, Hans and all, >> >>I have volunteered to review draft-ietf-alto-deployment-13. As time >>passes and the document is long, I prefer to send you my feedback >>piecewise, focusing first on the updated sections. For the sake of >>rapidity, I sometimes put Nits and other feedback together. >> >>So below, you will find my feedback on section 3.6. >>Then, I'll send you my feedback on sections 1 to 3.4 included. >> >>All in all, thanks for this clarified and enriched version of draft- >>ietf-alto-deployments. I found no major issues but some sentences need >>to be re-formulated and figures need be referenced in the text. Don't >>hesitate to get back to me if needed. >> >>Thanks, >>Sabine >> >>------------------------------------------------------ >>I used the following conventions: >> >>(1.2.3) section nb >>(p12) page nb >>para 2 = paragraph 2 >> >>(++ blabla) = added blabla >>(-- blabla) = removed blabla >>"old blabla" ==> "new blabla" = replace "old blabla" by "new blabla" >> >>--------- >>General: >> >>Figures 14 to 20: the caption should be harmonized with the rest of the >>document in that the common nouns should be written in low case and not >>start with a capital letter. >> >>In section 3.6.4 Calculation of Cost Map: many clarifications are >>needed on the path cost calculation >> >>--------- >>(p40) >>--------- >>para 1: "Figure 2" should be replaced by "Figure 15" as fas as I >>understand para 2: "listed information" ==> "listed information(++s)" >> >>--------- >>(p41) >>--------- >>- para 1: "As example" ==> "For example" >>- para 2: "information" ==> "information(++s)" >>- item 1: "Link" ==> "link" >>- (3.6.2), title: for transition to section 3.6.3 I suggest "Potential >>(++ input) Data Processing and Storage" >>- (3.6.2), para 3: to reference Figure 16, I suggest: "Each router >>could..." ==> "(++ As illustrated in Figure 16 for the router R2 of >>Figure 14,) each router could..." >> >>--------- >>(p42) >>--------- >>- item 2: to avoid hinting that an endpoint may be associated to >>several PIDs, I suggest: "AS numbers, or AS distances. >> Endpoints may belong to..." ==> "AS numbers (--,) or AS distances. >> Endpoints may be connected to" >>- para 2: "and/ or" ==> "and/or" >> >>- The presence of the remaining text "A suitable information... belongs >>to its own AS" before Figures 16 and 17 is pretty confusing, especially >>when encountering terms "weights" and "metrics". So I strongly suggest >>to move this remaining text after Figure 17 (p44). >> >>- instead: we need to reference Figure 16 and clarify the example >>attribute "Metric". So I suggest right after "just to name a few", to >>append "Figure 16 provides an example set of attributes associated to >>the router R2 of the exemple network depicted in Figure 14. The >>attribute "Metric" is an example of ... TBC" >> >>--------- >>(p43) >>--------- >>- Figure 16: please clarify what "default client subnet metric" can be >>- para 2: reference to Figure 17 needed. i suugest replacing "Router >>R8... " by "Figure 17 provides values for the same attributes >>associated to router R8. R8... " >> >>--------- >>(p44) >>--------- >>- para 1 (after text moved from p42): Insert ref to fig. 18, >>suggestion: "In the example, the link attributes..." ==> "Figure 18 >>provides an example where the link attributes..." >> >> >>--------- >>(p45) >>--------- >>- (3.6.3) title: in relation to (3.6.2) I suggest: "Calculation of >>Network Map (++from the Input Data)" >>- para 1: suggestion: "presentation of the network to a coarse-grained >>matrix presentation" ==> "(++re)presentation of the network to a >>coarse(++r) grained (++and abstracted) matrix (++re)presentation" >>- para 2: algorithm(++s) can utilize all (?? you mean "all" or "any" ?) >>information .... The functions ... to simplify the map or (--to) hide >>details ... published (--with) (++in) the resulting ALTO network map. >> >>--------- >>(p46) >>--------- >>- para 2: "Figure 14" ==> "Figure 19" >>- (3.6.4), para 1: "calculate values unidirectional" ==> "calculate >>unidirectional values" >> >>--------- >>(p47) >>--------- >>It is necessary to clarify the text on path calculation in this page. >> >>--- para 1: >>- "or subnet the cost" ==> "or subnet (++,) the cost" >>- "cost function may calculate" ==> "cost function may (++first) >>calculate" >>- "In that case a" ==> "In that case (++,) a" >>- "required which decide(--s)" ==> "required to decide..." >>- as this section is about computing values exposed by the ALTO Server, >>I suggested to append to following text. "resulting cost value" ==> >>"resulting cost value (++as RFC7285 allows one cost value only between >>2 PIDs.)" >>- Such (++a) tie-breaker can be (a++) simple function(--s) such as >>minimum, maximum, or average value. >> >> >>--- para 2: reformulation is needed here in order to cover the most >>"popular" optimal path extraction methods. >>- "the minimum path weight." ==> "the minimum weight path." >> >>- I recommend the following insertion: "The path weight is the sum..." >>==> "(++When the link weight is represented by an additive metric,) the >>path weight is the sum...". >>The reason is that: when the link weight metric represents a bandwidth >>performance, the metric composition law is "MIN" and path weight is >>equal to the smallest of the link weights. For a metric such as packet >>loss, the path weight is the multiplication over all links. >> >>- sentence "Hence, the cost function must first determine the path >>before it can determine any other metric value": besed on my previous >>comment, I'd rather say "Hence, the cost function generally extracts >>the optimal path w.r.t. a chosen metric". >> >>- sentence "As a result, the metric value can differ from the >>expectation where the path with the shortest path weight was not >>considered" is hard to understand and could be removed and replaced >>with some elaboration on the Dijkstra example. I will propose some >>formulation right after the next item. >> >>- "But it is also possible..." ==> "(--But) it is also possible..." >> >>- Suggestion for para 2 (let me know if I missed something) "No matter >>what metric the cost function is using, the path from source to >>destination is usually defined by the minimum (-+ weight) path. >> (++When the link weight is represented by an additive metric,) the >>path weight is the sum of the link weights of all traversed links. >> The path may be determined for instance with the Bellman-Ford or >>Dijkstra algorithm. The latter progressively builds the shortest path >>in terms of cumulated link lengths. In our example, the link lengths >>are link weights with values illustrated in Figure 15. (--2 sentences >>removed). (--But) It is also possible that more than one path..." >> >>--- para 3 >>- "values for other PID pairs for arbitrary reasons" ==> " values for >>some PID pairs due to arbitrary reasons" >> >> >>--- para 4 >>- "In this example, the selected >> metric..." ==> "Figure 20 provides an example where the selected >>metric..." >>- "from source to (++ the endpoints connected to the) destination PID": >>otherwise all the values in Figure 20 should be minus 1. >> >>--------- >>(p47) >>--------- >>para 1: "Due to the minimum value tie-breaker 3..." ==> "Due to the >>minimum (++hopcount)value tie-breaker (++,) 3..." >> >> >> >> >> >> >> >> >> >> >> >>>>-----Message d'origine----- >>>>De : alto [mailto:[email protected]] De la part de Vijay K. >>>>Gurbani Envoyé : mardi 26 janvier 2016 16:29 À : IETF ALTO Objet : >>>>[alto] State of the WG >>>> >>>>Folks: The mailing list has been awfully quiet. >>>> >>>>Presently, we have 3 active I-Ds that are being tracked towards >>>>charter >>>>fulfillment: >>>> >>>>1. draft-ietf-alto-deployments is in its second WGLC. The new WGLC >>>>ends >>>> on February 3, 2016. >>>> >>>>2. draft-ietf-alto-incr-update-sse appears to be moving along and >>>>there >>>> do not seem to be any stop gap issues that we are aware of. >>>>Authors, >>>> please inform the WG if there are. >>>> >>>>3. draft-ietf-alto-multi-cost is also fairly mature. >>>> >>>>It seems reasonable to move 2 and 3 ahead. >>>> >>>>Then there are a number of independent submissions dating back to >>Sep- >>>>Oct 2015 timeframe. These have not been updated and nor has there >>>>been much discussion on the mailing list. Some of these submissions >>>>are important for charter deliverables related to graph >>representation >>>>formats. Can the authors of the independent submissions kindly share >>>>what their plans are with respect to the drafts? >>>> >>>>This will help us gauge whether or not we should meet face-to-face in >>>>Buenos Aires or have an interim meeting before it and meet >>>>face-to-face in Berlin. >>>> >>>>Note that while the final plans are still up in the air and subject >>to >>>>change, there is a good chance that neither Jan or I will be able to >>>>make it to Buenos Aires. However, if a F2F meeting is desired, it is >>>>important to get a sense of the energy behind the independent drafts, >>>>as the list traffic has been woefully quiet on this front. >>>> >>>>Thanks, >>>> >>>>- vijay >>>>-- >>>>Vijay K. Gurbani, Bell Laboratories, Nokia 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 >> >>_______________________________________________ >>alto mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/alto
Hi Michael, Hans and all, As promised, here is my feedback to sections 1 to 3.4 included. I tried to separate "Nits only" and "nits + comments". In a first step, I am sending the review as an attachment. Again, thanks a lot for the work, this text is very well structured, clear and interesting. Some parts need a bit of clarifications and also, some re-phrasing to highlight the advantages of ALTO Services and providing incentives to use them is suggested here and there. Thanks, Sabine ------------------------------------------------------ I used the following conventions: (1.2.3) section nb (p12) page nb para 2 = paragraph 2 FOR THE REWORDING SUGGESTIONS (++ blabla) = added blabla (-- blabla) = removed blabla (-+ blabla) = replaced by blabla "old blabla" ==> "new blabla" = replace "old blabla" by "new blabla" ------------------------------------------------------ -------------------------- Comments and suggestions -------------------------- --- (2.2.1) Roles... The Abstract suggests a broad use for modern applications with resources including "processing services" and this sections seems to focus the ALTO scope on P2P and CDN. So I suggest a couple of sentences to enlarge the scope of ALTO information providers beyond the ISP. It would be good as well to enlarge the scope of applications beyond P2P and CDN by adding a sentence e.g. in section 2.1.2 with other examples of what an application endpoint, a user endpoint, a resource directory can be. - (2.1.1) Baseline... paragraph 1: how about a sentence giving examples of resource directories just before the figures? --------- p23 - (3.2.4) Rating Criteria... --------- This section provides an interesting classification of rating criteria. Suggested updates are listed below --- para 3: - "metric as (++the) basic set" - last sentence: for clarity I suggest to re-order the 2 propositions as follows: "It is up to the ALTO server how that metric is calculated" ==> "How that metric is calculated is up to the ALTO server" --- para 4: - "own network": need to clarify what "own" refers to. Do you mean "the network of the operator of the ALTO server" ? - "routing information (++,) networks" - "about its state" ==> "about -+their state" --- para 5: - "there is an extension procedure for adding": re-phrasing suggestion: "there is (++currently) a(--n) (+++protocol) extension procedure (--for adding) (+to add)" - After sentence "This list is not intended as normative text;": as far as I understod the text, I suggest to re-order the sentences of the rest of this paragraph as follows: "Instead, (--the) (++its) only purpose (--of the following list) is to document and discuss rating criteria that have been proposed so far. Whether such rating criteria are useful (--,) and whether the corresponding information would (--indeed) (++actually) be made available by ISPs (--it) can also depend on the use case of ALTO. A definition of further metrics can be found for instance in [I-D.wu-alto-te-metrics]." --------- p24-p25 --------- --- last item "Traffic volume caps": this item needs clarification. - "charged by "flat rate"..." =?=> "charged (--by) (++with a) "flat rate" - "candidate resource provider": you mean "candidate resource (-+location)" ? - "the amount of data": i suggest to add "the amount of data (++or its bitrate)" - "it would have to be indicated how excess traffic would be handled": (i) "(--it would have to be) (++ the ALTO Server may) indicate(--d) how excess traffic would be handled" (ii) it would help to give a hint on how this could be done, eg a new Endpoint Property ? - last sentence: "The interaction of several applications ... are for further study" is hard to understand and may need to be expanded (i) especially: "which issue ALTO queries on behalf of other endpoints," (ii) the relation of "interaction of several applications running on a host, out of which some use this criterion while others don't": how does this relate to ALTO Server information. I assume applications not using this information will simply have their excess traffic handled according the Traffic volume caps policy. Applications using it will be able to anticipate. (iii) "evaluation of this criterion in resource directories": you mean representation and encoding? --- item: "Other metrics": (i) this item is emblematic to the ALTO protocol and should emphasised, typically by putting it before the "traffic volume caps". (ii) I suggest to add that: this kind of metric is not available otherwise from "public" network monotoring tools and the abstract metric "routingcost" provided via RFC7285 is a key example. --- para 3: "These rating criteria" ==> "(++All the above listed) (--These) rating criteria" --- para 5: "... to the facts that (++ :)". please harmonize dots or commas at end of text throughout document. --------- p26 --------- --- para 3: after item 2: it would be useful to conclude/remind with 2-3 lines like "In other words, ALTO is a service to provide network information and policy on non-real time periods. Thereby, it avoids traffic oscillations and can help for network stability and cost optimization. --- (3.3) Known limitations of ALTO This section title as well as subtitles 3.3.* sound like "failures" of the ALTO protocol where as its content, in a very constructive way highlights the ALTO focus and possible ways around potential limitations. See sentence (p27) "If ALTO shall be deployed for use cases violating these assumptions, the protocol design may result in limitations." So I suggest some introduction to 3.3 and changes in section titles as follows: --- suggested title to 3.3: ALTO focus ans scope of efficiency --- suggested intro to section 3.3 (reword if needed) "The purpose of this section is to make sure that the users of the ALTO Services are cognizant of their goal and scope of efficiency which are based on the ALTO protocol focus and design. Using ALTO beyond this scope may limit its efficiency. Likewise, Map-based and Endpoint-based ALTO Services may face issues for which this section outlines proposed solution." --- (3.3.1) Limitations of using ALTO beyond design assumptions --------- p27 --------- --- (3.3.2), title: I suggest "Limitations of Map-based services and suggestions of solutions" --- para 1 of (3.3.2), last line: suggest "Map-based approaches" ==> "Map-based ALTO Services" --------- p29 --------- --- para 3: (3.3.2) could be concluded with the extension on incremental updates as a way to scalability. Some text like "To solve this issue, it has been suggested to use the incremental ALTO update services, which are being specified by the ALTO WG (+ add draft REF)." --- (3.3.3). Limitations of Non-Map-based Approaches, section title. I propose "Limitations of Endpoint-based services and suggestions of solutions" -------------------------- Nits (in sections with no other Comments) -------------------------- - section 1. Introduction paragraph 2 "This document provides guidance (++ on) which ALTO" - (2.1.2) Placement... paragraph 3: "ALTO service : If an" ==> "ALTO service : if an" - (2.2.1) Roles ... paragraph 4 "A key design... each these four" ==> "A key design... each (++of) these four" - (2.2.3) More advanced... page 11 * item 3: "Different ALTO Servers my..." ==> "Different ALTO Servers m(++a)y..." * last paragraph: ** "ISP operate" ==> "ISP(++s) operate" or "ISP operate(++s)" ** "this may (++be) true" - (3.1.1) General... paragraph 1: "The Internet provides network connectivity..." =?=> "The (new network operator) provides network connectivity..." - (3.1.2) Inter-network... Figure 5: not sure but how about "Caption" instead of "Legend"? - (3.1.3) Intra-Network paragraph 1 "ALTO provides guidance (++on) which internal.." - (3.1.4) Network... paragraph 1: "load cause(++d)" - (3.2.2) Data collection... paragraph 1: "Topology data sources (--that) may include..."
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
