Hi Éric,
Thank you so much for the update.
For the comment on IPv4: we had some discussions on how to address it. In
earlier documents, we used a mix of IPv4 and IPv6 addresses (e.g., an
earlier version of RFC7285 used a mix of ipv4 and ipv6 in examples such as
https://datatracker.ietf.org/doc/html/rfc7285#section-11.5.1.7), and the
feedback was that this could be confusing, and hence we used only ipv4
addresses. We see two possibilities: (1) add one example, say replicating
Example 1, but with ipv6; and (2) change one of the late examples, say
example 2, from ipv4 to ipv6 addresses.
For the TCP model, the examples we gave (
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-26#section-4.1)
mentioned both Cubic and BBR. Does this address the comment? Or the
suggestion is to change the metric from "TCP Throughput" to something like
"Congestion Control Throughput" to be more general?
Please let us know and we sure can take a pass.
Thank you so much again!
Richard
On Fri, Mar 4, 2022 at 5:57 AM Éric Vyncke via Datatracker
wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-alto-performance-metrics-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>
>
>
> --
> COMMENT:
> --
>
> 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' ?
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
