Re: [alto] Chair review of path-vector-13 (Part 1 of 2)
Hi Vijay and the ALTO WG, This is a follow-up on the comments that are not fully address in the previous email. Please see below. Thanks! Best, Kai -Original Messages- From:"Vijay Gurbani" Sent Time:2021-02-08 23:35:13 (Monday) To: draft-ietf-alto-path-vec...@ietf.org Cc: "IETF ALTO" Subject: Chair review of path-vector-13 (Part 1 of 2) Chair review from beginning of document to the end of S6.6. Part 1 of 2. Major: - S4.1, below Figure 2: Note that we do not have "availbw" defined in ALTO as a current cost metric, so it is not a good idea to use it here without qualifying it further. If used as is, it creates confusion. My advice would be to either qualify the use of "availbw" as a hypothetical cost metric, or choose an actual cost metric from the performance-metric draft and restate the example. - S4.1, "Case 1": I don't see how the "application will obtain 150 Mbps at most." Consider that the bottleneck bandwidth is 100 Mbps, as that is the bandwidth of the most constrained link. Once traffic leaves sw5, it can get no more than 100 Mbps on the remaining links. So, I don't understand how the "application will obtain 150 Mbps at most."? Perhaps I am missing something? - S4.2.3: This paragraph, especially the second sentence onwards needs to be re-written to better flesh out the need. Currently it says, "While both approaches...", however, it is not clear that there are two approaches being delineated from each other here. It needs more edits so it reads better. (Some nits in this paragraph appear in the Nits section trying to tease out the language.) - S5.1.3: When Section 5 begins, it says that "This section gives a non-normative overview of the Path Vector extension." However, in S5.1.3, there is a normative "MUST". (Same problem in S5.3, there are many "MUST"s there, and in Section 5.3.3 there are "RECOMMENDED" and "SHOULD NOT".) Generally, I am a bit hesitant that certain subsections of Section 5 --- Section 5.3.2 in particular --- appear to contain normative behaviour, and this should be specified in a normative section, or do NOT start Section 5 by saying that this section gives a non-normative overview, and make this a normative section. I understand this is a major comment, so please think how you want to handle this carefully. - S5.3.2: Not sure I follow the logic in the first paragraph. As Fig. 4 showed, there is one PV request, and if ALTO SSE extension is being used, presumably, it will contain the "client-id". If the response contains a Path Vector resource, shouldn't that "client-id" simply apply to it? I am sure I am missing something here as you have thought about this more than me; perhaps you could add a simple example to make the problem more explicit. - S6.4: Why have a mini Security Considerations paragraphs in the subsections of S6.4, but not in the subsections of S6.3 and S6.5? I am not saying that you remove the mini Security Considerations paragraphs, but if there are security considerations worth pointing out in S6.4, I suspect that there are security considerations worth pointing out in S6.3 and S6.5? (One such security consideration is listed below in S6.5.1.) - S6.4.2: "The persistent entity ID property is the entity identifier of the persistent ANE which an ephemeral ANE presents (See Section 5.1.2 for details)." ==> I am not sure what this means? Why is an ephemeral ANE presenting a persistent entity identifier? Is it important that you are defining an ephemeral ANE and associating it with persistent entities? If so, then please make this clear as there is a lot of ambiguity in this section. - S6.5.1: What is the effect if the ALTO server chooses to obfuscate the path vector, causing the client to experience sub-optimal routing. The client does not know that the server has obfuscated the path vector, so it MUST interpret the path vector as given to it by the ALTO server. This raises the question whether such obfuscation, because it is indistinguishable from a non-obfuscated response, creates an attack on the client? (Would a mini Security Consideration paragraph be appropriate here?) Clearly, since ALTO assumes that the server is trusted to some degree, the issue becomes (a) can the client, by repeated querying, figure out that it is being duped on occasion? (b) what does it then do? [PV] The effects are highly implementation-specific, and it is true that obfuscation may create an attack on the client by compromising the integrity of ALTO information. As we discuss in Section 11, there are some obfuscation methods that can preserve the integrity of the information. Regarding the last two issues, the answer to (a) is also implementation- and network-specific, if the obfuscation is idempotent, i.e., generating the same obfuscated results for the same request, a client will not be able to figure out that it is being duped; even if a client sees two
[alto] Chair review of path-vector-13 (Part 1 of 2)
Chair review from beginning of document to the end of S6.6. Part 1 of 2. Major: - S4.1, below Figure 2: Note that we do not have "availbw" defined in ALTO as a current cost metric, so it is not a good idea to use it here without qualifying it further. If used as is, it creates confusion. My advice would be to either qualify the use of "availbw" as a hypothetical cost metric, or choose an actual cost metric from the performance-metric draft and restate the example. - S4.1, "Case 1": I don't see how the "application will obtain 150 Mbps at most." Consider that the bottleneck bandwidth is 100 Mbps, as that is the bandwidth of the most constrained link. Once traffic leaves sw5, it can get no more than 100 Mbps on the remaining links. So, I don't understand how the "application will obtain 150 Mbps at most."? Perhaps I am missing something? - S4.2.3: This paragraph, especially the second sentence onwards needs to be re-written to better flesh out the need. Currently it says, "While both approaches...", however, it is not clear that there are two approaches being delineated from each other here. It needs more edits so it reads better. (Some nits in this paragraph appear in the Nits section trying to tease out the language.) - S5.1.3: When Section 5 begins, it says that "This section gives a non-normative overview of the Path Vector extension." However, in S5.1.3, there is a normative "MUST". (Same problem in S5.3, there are many "MUST"s there, and in Section 5.3.3 there are "RECOMMENDED" and "SHOULD NOT".) Generally, I am a bit hesitant that certain subsections of Section 5 --- Section 5.3.2 in particular --- appear to contain normative behaviour, and this should be specified in a normative section, or do NOT start Section 5 by saying that this section gives a non-normative overview, and make this a normative section. I understand this is a major comment, so please think how you want to handle this carefully. - S5.3.2: Not sure I follow the logic in the first paragraph. As Fig. 4 showed, there is one PV request, and if ALTO SSE extension is being used, presumably, it will contain the "client-id". If the response contains a Path Vector resource, shouldn't that "client-id" simply apply to it? I am sure I am missing something here as you have thought about this more than me; perhaps you could add a simple example to make the problem more explicit. - S6.4: Why have a mini Security Considerations paragraphs in the subsections of S6.4, but not in the subsections of S6.3 and S6.5? I am not saying that you remove the mini Security Considerations paragraphs, but if there are security considerations worth pointing out in S6.4, I suspect that there are security considerations worth pointing out in S6.3 and S6.5? (One such security consideration is listed below in S6.5.1.) - S6.4.2: "The persistent entity ID property is the entity identifier of the persistent ANE which an ephemeral ANE presents (See Section 5.1.2 for details)." ==> I am not sure what this means? Why is an ephemeral ANE presenting a persistent entity identifier? Is it important that you are defining an ephemeral ANE and associating it with persistent entities? If so, then please make this clear as there is a lot of ambiguity in this section. - S6.5.1: What is the effect if the ALTO server chooses to obfuscate the path vector, causing the client to experience sub-optimal routing. The client does not know that the server has obfuscated the path vector, so it MUST interpret the path vector as given to it by the ALTO server. This raises the question whether such obfuscation, because it is indistinguishable from a non-obfuscated response, creates an attack on the client? (Would a mini Security Consideration paragraph be appropriate here?) Clearly, since ALTO assumes that the server is trusted to some degree, the issue becomes (a) can the client, by repeated querying, figure out that it is being duped on occasion? (b) what does it then do? Minor: - S1, paragraph 3: Why would "job completion time" be shared by bottleneck network links? On first glance, job completion time is a function of the compute resources on the host not network links, but on further reflection, job completion time could also be a function of the network links on the host if the data needs to be marshalled to the job (process) in order for it to complete. If so, then perhaps reword as: OLD: For example, job completion time, which is an important QoE metric for a large-scale data analytics application, is impacted by shared bottleneck links inside the carrier network. NEW: For example, job completion time, which is an important QoE metric for a large-scale data analytics application, is impacted by shared bottleneck links inside the carrier network as link capacity may impact the rate of data input/output to the job. - S5.1.1: "Thus they must follow the mechanisms specified in the [i-D.ietf-alto-unified-props-new]." ==> Here, it may help to point
