[alto] Chair review of path-vector-13 (Part 1 of 2)

[Vijay Gurbani <[e-mail]>]

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 to a
specific section of the I-D you want the implementer to follow the
mechanisms of.  Do you mean the naming mechanism defined in the I-D?  The
inheritance mechanism defined in the I-D?

- S5.1.2: How does the client know that an ANE in a response is ephemeral
versus persistent?  You answer this question in Section 6.4.2, perhaps you
can put a forward reference to Section 6.4.2 as I am sure other readers
will have the same question.

- S6.2.4: "...their entity domain names MUST be ".ane"..." ==> MUST be .ane
or MUST use the .ane prefix?  I can't tell.  Please specify this better
through an example as well.  You do have an example in the last paragraph,
but the writing of the example is ambiguous.  My understanding is:
".ane:NET1" is an ephemeral ANE, while "dc-props.ane:DC1" is a persistent
ANE.  Is that correct?  If so, just explicitly mention this.

Nits:

- S4.1: s/the scheduling.  However,/the scheduling, however,/

- S1, paragraph 3: s/applications, however, the/applications, the/

- S1, paragraph 5: s/in a huge volume/in an increase in volume/

- S1: s/The pressure on the/The requirements on the/

- S1: s/ALTO server convey/ALTO server to convey/

- S1: s/that each identifies/that identifies/
  or
      s/that each identifies/, each element of which identifies/

- S3: s/in a cost map or for a/in a cost map, or for a/

- S4.2.1: s/Gigabytes, Terabytes, and even Petabytes/gigabytes, terabytes,
and even petabytes/
(Reason: there is no need to gratuitously capitalize these.)

- S4.2.1: s/related to the completion time of the slowest data
transfer./related to the data transfer time over the slowest link./

- S4.2.1: s/the Path Vector extension/the extension defined in this
document/
(This is repeated in S4.2.2 and perhaps elsewhere, please consider it as a
request for global change.)

- S4.2.2: s/It is getting important/It is important/

- S4.2.3: s/may have to make/will need/

- S4.2.3: s/and potentially with/and potentially need/

- S5.2: s/, meaning the/, this means that the/

Thanks,

- vijay