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

[[e-mail]]

Hi Vijay and the ALTO WG,




Thanks for the review and please find the responses inline. We will fix the missing items as soon as possible.




Best,

Kai



-----Original Messages-----
From:"Vijay Gurbani" <[e-mail]>
Sent Time:2021-02-11 00:23:13 (Thursday)
To: [e-mail]
Cc: "IETF ALTO" <[e-mail]>
Subject: [alto] Chair review of path-vector-13 (Part 2 of 2)


Dear Authors: This part concludes my chair review of path-vector, an important ALTO extension.  Thank you for your work on this document.  I hope the comments in this part and the first part help position the document better.


Chair review from Section 7 to the end of the document.
Part 2 of 2.



Global comment: Please turn all "Content-Length: [TBD]" into "Content-Length: XXX", where "XXX" is the computed content length.




[PV] This comment has not been addressed yet but is being processed.


Major:

- S7.1.3: When you first get into JSON object declarations, you should point the reader to S8.2 of RFC7285, where the semantics related to the syntax used to declare ALTO JSON objects is defined.  This will help new implementers who


pick up this manuscript and need to understand where the declaration syntax, and previously declared JSON ALTO objects, like ReqFilteredCostMap, reside.




[PV] Thanks for the comment. We add a subsection "Notations" in Section 7 and point to S8.2 of RFC 7285. References to the previous defined JSON objects are also added to the text where the previously defined objects are referenced.


- S8.3: I think the ALTO response deserves a longer explanation here.  Let me see if I understand correctly: the cost map returns two properties: NET1 and AGGR.  On NET1, the max reservable bandwidth is 50 Gb (or GB?), i.e., inside the NET1 abstraction of Figure 5, the max reservable bandwidth is much higher than the link bandwidth.  For the AGGR (BTW, what does AGGR stand for?  Minimum aggregate bandwidth?), the max reservable bandwidth is 10 Gbps, which is the bandwidth of L1.  Yes?  Please expand the explanation in the document to be as explicit as you can.



Further, my suggestion would be to show the NET1 and AGGR from source 2.3.4.5 to destination 4.5.6.1, because that will necessarily include traversing two links, L1 and L2.  What would be the AGGR there?




[PV] The previous example in 8.3 is actually the result after obfuscation where the AGGR encapsulates the subnetwork NET1 and the connectivity between NET1 and NET3. We now give two response examples in 8.3. The first example gives the "raw" response and the second example is an obfuscated response.




- S9.2: I am not sure what the prescription here is.  Whatever it is, it needs to be (a) explicit, and (b) stronger.  Current text says that this document does not "specify" the use of path vector cost type with RFC 8189.  Why does it not specify this?  Is it because such integration is not possible?  In which case, the document should say so.  Or is it because the authors have not studied whether such integration makes sense and can be supported in a backward compatible manner?  If so, well, say so.  Or is it because such integration is not possible at all?  If so, say so.  This is a protocol document, we need to be as unambiguous as possible.  (S9.3 is a good example of drawing a line in the sand.) 




[PV] We have rewritten the subsection to clarify the compatibility issue with the multi-cost extension. In particular, we explain why these two extensions cannot be used together.




NEW:

   The extension defined in this document is NOT compatible with the
   multi-cost extension [RFC8189].  The reason is that if a resource
   supports both the extension defined in this document and the multi-
   cost extension, the media type of this resource depends on the
   selection of cost types: if the path vector cost type is selected,
   the media type of the response is either "multipart/related;
   type=application/alto-costmap+json" or "multipart/related;
   type=application/alto-endpointcost+json"; if the path vector cost
   type is not selected, the media type of the response is either
   "application/alto-costmap+json" or "application/alto-
   endpointcost+json".

   Note that this problem may happen when an ALTO information resource
   supports multiple cost types, even if it does not enable the multi-
   cost extension.  Thus, Section 7.2.4 has specified that if an ALTO
   information resource enables the extension defined in this document,
   the path vector cost type MUST be the only cost type in the "cost-
   type-names" capability of this resource.





- S10.2: Not sure why the MAY is normative here.  This paragraph should be re-written in its entirety; it reads more like a draft set of notes than something well thought out.




[PV] Thanks for the comment. We revise the subsection to include more discussions on the topic and propose potential directions.




OLD:

   Querying multiple ALTO information resources continuously MAY be a
   general requirement.  And the coming issues like inefficiency and
   inconsistency are also general.  There is no standard solving these
   issues yet.  So we need some approach to make the ALTO client request
   the compound ALTO information resources in a single query.




NEW:

   Querying multiple ALTO information resources continuously is a
   general requirement.  Enabling such a capability, however, must
   address the general issues like efficiency and consistency.  The
   incremental update extension [RFC8895] supports submitting multiple
   queries in a single request, and allows flexible control over the
   queries.  However, it does not cover the case introduced in this
   document where multiple resources are needed for a single request.

   This extension gives an example of using a multipart message to
   encode two specific ALTO information resources: a filtered cost map
   or an endpoint cost map, and a property map.  By packing multiple
   resources in a single response, the implication is that servers may
   proactively push related information resources to clients.

   Thus, it is worth looking into the direction of extending the SSE
   mechanism as used in the incremental update extension [RFC8895], or
   upgrading to HTTP/2 [RFC7540] and HTTP/3 [I-D.ietf-quic-http], which
   provides the ability to multiplex queries and to allow servers
   proactively send related information resources.

   Defining a general multi-resource query mechanism is out of the scope
   of this document.





- S11, last paragraph: I am not sure what "intolerable increment of the server-side storage" means here.  Isn't the issue more along the lines of spending CPU cycles doing path computation rather than storage requirements? Conflating "storage" here does not seem to be warranted, but perhaps I am mistaken.  Please advise.

Further, the text says, "To avoid this risk, authenticity and authorization of this ALTO service may need to be better protected." ==> I am unsure how this helps.  The ALTO server has no means to authenticate the client, nor does it have any means to know whether the client is authorized to send it a request.  Consequently, the best it can do to protect itself is to monitor client behaviour and stop accepting requests if the client misbehaves (sends same requests frequently, sends requests with small deltas frequently, or it can ask the client to solve some puzzle before submitting a request, etc.).  But generally, this class of resource exhaustion attacks are hard to defend against, and I am not sure that we will come up with something that is definitely prescriptive here.  But we should structure the discussion such that it appears that we have thought of the issues here.





[PV] Thanks for the comment. We have revised the paragraph to address both comments: we add the computation overhead, and add a sentence describing how an ALTO server may protect itself from malicious clients.




OLD:

   To avoid this risk, authenticity and authorization
   of this ALTO service may need to be better protected.  Also, an ALTO
   server may consider using optimizations such as precomputation-and-
   projection mechanisms [JSAC2019].





NEW:

   To mitigate this risk, an ALTO server may consider using
   optimizations such as precomputation-and-projection mechanisms
   [JSAC2019] to reduce the overhead of processing each query.  Also,
   an ALTO server may also protect itself from malicious clients by
   monitoring the behaviors of clients and stopping serving clients with
   suspicious behaviors (e.g., sending requests at a high frequency).





Minor:



- S7.1.6, bullet item "The Unified Property Map part MUST also include "Resource-Id" and "Content-Type" in its header." ==> Doesn't the unified-props I-D already mandate this?  If so, why repeat it here?




[PV] In fact, this bullet item is related to the multipart format and is not specified in the UP I-D.


- S9: I would suggest changing the title to "Compatibility with other ALTO extensions"





[PV] The title of S9 is changed as suggested.




- S10.1, paragraph 3: I would suggest the following re-write for this paragraph:

"In practice, developing a bespoke language for general-purpose boolean tests can be a complex undertaking, and it is conceivable that there are some existing implementations already (the authors have not done an exhaustive search to determine whether there are such implementations).  One avenue to develop such a language may be to explore extending current query languages like XQuery or JSONiq and integrating these with ALTO."



(Please provide references for XQuery and JSONiq.)




[PV] The text is changed as suggested and the references are provided.




Nits:




[PV] The proposed changes are adopted as they are unless specifically explained.


- S8.1: s/The example ALTO server provides/Assume that an ALTO server provides/

- S9.1: s/conducting any incompatibility./incurring any incompatibility problems./

- S11: s/requires additional considerations/requires additional scrutiny/

-S11: s/authenticity and authorization/authentication and authorization/


Thank you!