[alto] Benjamin Kaduk's Discuss on draft-ietf-alto-performance-metrics-21: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-alto-performance-metrics-21: 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 addressing my previous discuss points with the -21 (and my
apologies for the spurious one!); I'm glad to see that they were indeed
easy to address.

However, I have looked over the changes from -20 to -21 and seem to have
found a couple more issues that should be addressed:

(1) I can't replicate the Content-Length values in the examples (I only
looked at Examples 1 and 2).  Can you please share the methodology used
to generate the values?  My testing involved copy/paste from the
htmlized version of the draft to a file, manually editing that file to
remove the leading three spaces that come from the formatting of the
draft, and using Unix wc(1) on the resulting file.  It looks like the
numbers reported in the -21 are computed as the overall number of
characters in the file *minus* the number of lines in the file, but I
think it should be the number of characters *plus* the number of lines,
to accommodate the HTTP CRLF line endings.  (My local temporary files
contain standard Unix LF (0x0a) line endings, verified by hexdump(1).)

(2) We seem to be inconsistent about what the "cur" statistical operator
for the "bw-utilized" metric indicates -- in §4.4.3 it is "the current
instantaneous sample", but in §4.4.4 it is somehow repurposed as "The
current ("cur") utilized bandwidth of a path is the maximum of the
available bandwidth of all links on the path."


--
COMMENT:
--

I cannot currently provide a concise explanation of the nature of my
unease with the "bw-utilized" metric specification that is new in this
revision (so as to elevate it to a Discuss-level concern), but I
strongly urge the authors and WG to consider my comments on Section 4.4.3.

The new text in Section 1 explaining the origins of the metrics (e.g.,
from TE performance metrics) and why some other TE metrics are not
defined is nicely done.  I trust the responsible AD and WG chairs to
ensure that it, and the other places where we have added new exposition,
has gotten the appropriate level of review from the WG membership.

Section 3.1.2, 3.2.2

I see that the delay-ow and delay-rt semantics have been changed from
milliseconds to microseconds going from -20 to -21.  Either
representation seems fine, but it may be risky to make such a change so
late in the publication process, especially if there are already
implementations in place.  I also don't see any AD ballot comments that
seem to motivate the change, so I'm a bit curious how it arose -- is it
for consistency with the corresponding TE link metrics?

Section 3.3.3

   Intended Semantics: To specify temporal and spatial aggregated delay
   variation (also called delay jitter)) with respect to the minimum
   delay observed on the stream over the one-way delay from the
   specified source and destination, where the one-way delay is defined
   in Section 3.1.  A non-normative reference definition of end-to-end
   one-way delay variation is [RFC3393].  [...]

I note that RFC 3393 explicitly says that as part of the metric, several
parameters must be specified, most notably the selection function F that
unambiguously defines the two packets selected for the metric.  While
it's allowed for F to select as the "first" packet the one with the
smallest one-way delay, which maps up to the "with respect to the
minimum delay observed on the stream" here, it seems to me that it's
fairly important to call out that we are not allowing the full
flexibility of the RFC 3393 metric.  Assuming, of course, that we
specifically have that as the intent, versus allowing the full
generality of RFC 3393.  If there has been some research results since
RFC 3393 was published that indicate that it's preferred to use the
minimum delay for this purpose, that might be worth listing as a
reference in addition to RFC 3393.

Section 3.4.4

The estimation of end-to-end loss rate as the sum of per-link loss rates
is (1) only valid in the low-loss limit, and (2) assumes that each
link's loss events are uncorrelated with every other link's loss events.
The current text does mention (2) in the form of "should be cognizant of
correlated loss rates", but I don't think it 

[alto] Meeting Info for Dec 21, 2021

[kaigao]

Dear all,



This is a friendly reminder that we will have the ALTO weekly meeting at 9:00 
am EST (3:00 pm CET and 10:00 pm Beijing Time) on Tuesday, Dec 21, 2021.




Agenda:

- GradientGraph and its applications (G2 team)

- IETF WG drafts and new charter items




Bridge:


https://yale.zoom.us/my/yryang




Best,

Kai___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Martin Duke]

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  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) 
> 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
>> ] 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 
>> *Date: *Monday, 22 November 2021 at 16:40
>> *To: *Eric Vyncke 
>> *Cc: *The IESG , alto-chairs , "
>> draft-ietf-alto-performance-metr...@ietf.org" <
>> draft-ietf-alto-performance-metr...@ietf.org>, IETF ALTO ,
>> Jan Seedorf 
>> *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 <
>> nore...@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 

[alto] I-D Action: draft-ietf-alto-path-vector-20.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

Title   : An ALTO Extension: Path Vector
Authors : Kai Gao
  Young Lee
  Sabine Randriamasy
  Yang Richard Yang
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-path-vector-20.txt
Pages   : 65
Date: 2021-12-20

Abstract:
   This document is an extension to the base Application-Layer Traffic
   Optimization (ALTO) protocol.  It extends the ALTO Cost Map and ALTO
   Property Map services so that an application can decide which
   endpoint(s) to connect based on not only numerical/ordinal cost
   values but also details of the paths.  This is useful for
   applications whose performance is impacted by specified components of
   a network on the end-to-end paths, e.g., they may infer that several
   paths share common links and prevent traffic bottlenecks by avoiding
   such paths.  This extension introduces a new abstraction called
   Abstract Network Element (ANE) to represent these components and
   encodes a network path as a vector of ANEs.  Thus, it provides a more
   complete but still abstract graph representation of the underlying
   network(s) for informed traffic optimization among endpoints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-20.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-20


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto