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
