Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics
draft-ietf-alto-performance-metrics-28

[S3.4.2; comment]

* I would recommend specifying a maximum value as well.  It's not clear
  how values greater than the 8-bit TTL/HopLimit fields can carry should
  be interpreted.

  I would recommend max 254, as 255 tends to have special interpretation.

Thank you for the work on this document, and for addressing my previous DISCUSS points.

Many thanks to Christian Amsüss for his review: https://mailarchive.ietf.org/arch/msg/art/owYhcoFnl1vEipZ2D62cWiiE-LA/ , and thanks to the authors for addressing it.

Francesca

I support Francesca's DISCUSS.

I suggest breaking Section 7 into separate subsections for each request.  Specifically, the registrations in the first paragraph should be clearly separated from the creation of the registry that starts below that.

Maybe I'm turning into a dinosaur, but since all of the syntaxes in these documents are constrained to US-ASCII, I wonder why listing Unicode characters individually, or ranges of them (e.g., Section 2.1), is preferred to using ABNF.

All of the SHOULDs in this document feel weak to me.  I can't tell, for example, why an implementer might do anything other than what follows the SHOULD, which suggests to me that they should be MUSTs.  If there's some reason to leave the option there, I think some supporting text would be warranted.

Thanks to Vincent Roca for the SECDIR review.

** Section 1.
An ALTO server may provide only a subset of the metrics described in
   this document.  For example, those that are subject to privacy
   concerns should not be provided to unauthorized ALTO clients.  

Is this generic caution, or are any of the mentioned metrics considered privacy sensitive in some way?

** Section 2.1.  Editorial.  s/, and “sla”/, “sla”/

** Examples 1 – 7 all have a their “Content-Length” set to “TBA”.  Consider populating it with the real length of each of the examples.

** Nit.  Example 7 (in Section 4.2.4) comes earlier than Example 6 (in Section 4.3.3)

** Section 6.  In the spirit of inclusively, please rephrase “man-in-the-middle (MITM) attacks”

** Additional Security Considerations. It appears that in cases of an “sla” and certain “estimation” cost-estimates, it is recommended for a URI to be provided via the parameters field to point to additional information.

-- is there any further guidance that can be provided on how this URI can be secured.  Perhaps, requiring https?

-- additional, I would recommend guidance to this effect (please polish the language on what exact ALTO fields are in question):

When ALTO clients process the URIs in the “link” field provided in the “parameters” field of select “sla” and “estimation” cost-estimate metrics, they should heed the risks outlined in Section 7 of RFC3986.

Based of our email discussion and agreed changes ( working copy here : https://github.com/ietf-wg-alto/draft-ietf-alto-performance-metrics), I am balloting no Objection. Thanks for addressing my discuss and comments.

Thank you for addressing my previous DISCUSS point, I have now updated my ballot position into a NO OBJECT.

Nevertheless, I would have appreciated a reaction on the IPv4-only examples and the focus on TCP only but this is obviously not blocking this document. I appreciate that my other comments were used to improve the document.

Regards

-éric

—— below is for archiving only —


Thank you for the work put into this document. Please bear with my lack of knowledge about ALTO in general.

Please find below one trivial blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jan Seedorf for the shepherd's write-up about the WG consensus (even if not using the usual template).

I have appreciated the "operational considerations" section as it addresses many questions that popped up during reading the document; notably, how can the ALTO server measure any metric between the ALTO client and a resource.

I hope that this helps to improve the document,

Regards,

-éric


== COMMENTS ==

Minor regret about the examples as they are all about the IPv4 address family especially in a world of happy eyeballs where the IPv4 and IPv6 paths may still have different performance metrics.
 
-- Section 2.1 --
Should the figure 1 use "perf monitoring tools" rather than "management tool" ?

-- Section 4 --
This section title is about 'bandwidth' but the first sub-section is about 'throughput', while these concepts are related they are also distinct. How can the reader reconciliate them ?

-- Section 4.1 --
Is the intent of ALTO to only work for TCP and not for other transport protocols ? I.e., is QUIC out of scope ?


-- Section 4.2.3 --
Where are those 'tunnels' in "by subtracting tunnel reservations " coming from ? Probably about RSVP-TE but what is the link with ALTO ? (Again I am not familiar with ALTO so this may be an uneducated question).

== NITS ==


-- Section 3.1.3 --
Probably tedious to do but why not replacing "TBA" by the actual value in the examples for 'content-length' ?

Thanks for the updates from -21 through -26, and my apologies to have
taken so long to review the changes!

My previous discuss point about the "cur" operator of the "bw-utilized"
metric is no longer relevant after the removal of that metric from this
document.  I also appreciate the updated examples (including
Content-Length); I seem to now get values that are off by one from what's
currently in the -26, but given that the authors have consciously looked
into the topic and I have low confidence in my own methodology, I will
drop that as a Discuss point.