Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

Hi Eric,

We have posted the latest version at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-25

Could you please take a look to make sure that we have addressed your
DISCUSS and COMMENTS?

In particular,
- We updated the normative references such as RFC8312bis
- We changed the figure to "perf monitoring tools"
- We changed Sec. 4 titles to be consistent
- We fixed all references.

If you find any new issues that we should address, please let us know and
we will fix them with a short turn-around time.

Thank you so much again!
Richard

On Tue, Dec 21, 2021 at 9:55 AM Y. Richard Yang <yry@cs.yale.edu> wrote:

> Hi Eric, Martin, all,
>
> The authors agree that 8312bis should be a normative reference, and it is
> in -v22, which we will upload soon.
>
> Thanks,
> Richard
>
> On Tue, Dec 21, 2021 at 8:52 AM Qin Wu <bill.wu=
> 40huawei.com@dmarc.ietf.org> wrote:
>
>> I agree with Martin, 8312bis should be listed as normative reference. We
>> will correct this in v-22.
>>
>>
>>
>> -Qin
>>
>> *发件人:* alto [mailto:alto-bounces@ietf.org] *代表 *Martin Duke
>> *发送时间:* 2021年12月20日 23:27
>> *收件人:* Eric Vyncke (evyncke) <evyncke@cisco.com>
>> *抄送:* alto-chairs <alto-chairs@ietf.org>;
>> draft-ietf-alto-performance-metrics@ietf.org; The IESG <iesg@ietf.org>;
>> IETF ALTO <alto@ietf.org>
>> *主题:* Re: [alto] Éric Vyncke's Discuss on
>> draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)
>>
>>
>>
>> Authors,
>>
>>
>>
>> 8312bis is still in the informational references; is this an oversight,
>> or are you arguing that it's not normative?
>>
>>
>>
>> On Mon, Nov 22, 2021 at 8:39 AM Martin Duke <martin.h.duke@gmail.com>
>> wrote:
>>
>> Good catch!
>>
>>
>>
>> I'm not sure that either of these references are actually directly
>> relevant to the subject, though I'm happy to be convinced otherwise.
>>
>>
>>
>> It might be that one of the IPPM docs (RFC 8337?) might be a better fit.
>>
>>
>>
>> If RFC 8312 is the right answer, 8312bis is almost done and they can
>> simply update to avoid the downref.
>>
>>
>>
>> Martin
>>
>>
>>
>> On Mon, Nov 22, 2021 at 7:54 AM Eric Vyncke (evyncke) <evyncke@cisco.com>
>> wrote:
>>
>> Martin,
>>
>>
>>
>> The text in § 4.1.3 says:
>>
>>    Intended Semantics: To give the throughput of a TCP congestion-
>>
>>    control conforming flow from the specified source to the specified
>>
>>    destination; see [RFC3649, Section 5.1 of RFC8312
>> <https://datatracker.ietf.org/doc/html/rfc8312#section-5.1>] on how TCP
>>
>>    throughput is estimated.  The spatial aggregation level is specified
>>
>>    in the query context (e.g., PID to PID, or endpoint to endpoint).
>>
>>
>>
>> So, it is RFC 8312 in the text, RFC 8312 is vaguely related to TCP
>> bandwidth
>>
>>
>>
>> -éric
>>
>>
>>
>> *From: *Martin Duke <martin.h.duke@gmail.com>
>> *Date: *Monday, 22 November 2021 at 16:40
>> *To: *Eric Vyncke <evyncke@cisco.com>
>> *Cc: *The IESG <iesg@ietf.org>, alto-chairs <alto-chairs@ietf.org>, "
>> draft-ietf-alto-performance-metrics@ietf.org" <
>> draft-ietf-alto-performance-metrics@ietf.org>, IETF ALTO <alto@ietf.org>,
>> Jan Seedorf <ietf@j-f-s.de>
>> *Subject: *Re: Éric Vyncke's Discuss on
>> draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)
>>
>>
>>
>> Thanks Eric,
>>
>>
>>
>> I think you mean RFC 8321? I am in the early stages of AD sponsoring a
>> draft to update that to PS. The authors have the choice of doing a downref
>> or referring to 8321bis and being stuck in the RFCEd queue for a few extra
>> months.
>>
>>
>>
>> On Mon, Nov 22, 2021 at 3:32 AM Éric Vyncke via Datatracker <
>> noreply@ietf.org> wrote:
>>
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-alto-performance-metrics-19: Discuss
>>
>> 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/blog/handling-iesg-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/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> 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
>>
>> == DISCUSS ==
>>
>> -- Section 4.1.3 --
>> A very trivial DISCUSS to fix: this document relies on RFC 8312 to
>> specify how
>> TCP throughput is estimated but RFC 8312 does not appear in the normative
>> reference list (this will probably generate a down ref though).
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> == 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
>>
>
>