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 <[email protected]> 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= > [email protected]> wrote: > >> I agree with Martin, 8312bis should be listed as normative reference. We >> will correct this in v-22. >> >> >> >> -Qin >> >> *发件人:* alto [mailto:[email protected]] *代表 *Martin Duke >> *发送时间:* 2021年12月20日 23:27 >> *收件人:* Eric Vyncke (evyncke) <[email protected]> >> *抄送:* alto-chairs <[email protected]>; >> [email protected]; The IESG <[email protected]>; >> IETF ALTO <[email protected]> >> *主题:* 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 <[email protected]> >> 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) <[email protected]> >> 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 <[email protected]> >> *Date: *Monday, 22 November 2021 at 16:40 >> *To: *Eric Vyncke <[email protected]> >> *Cc: *The IESG <[email protected]>, alto-chairs <[email protected]>, " >> [email protected]" < >> [email protected]>, IETF ALTO <[email protected]>, >> Jan Seedorf <[email protected]> >> *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 < >> [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
