Re: [alto] [PANRG] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01

[Qin Wu]

Here is an interesting work from IAB, which is built on top of RFC8558, also 
related to draft-irtf-panrg-questions recommended by Martin
https://datatracker.ietf.org/doc/draft-arkko-iab-path-signals-collaboration/
especially section 3.4, if you have any comments or input to this work, please 
share on the list or send them to the chairs, many thanks!

-Qin (on behalf of chairs)
-邮件原件-
发件人: Panrg [mailto:panrg-boun...@irtf.org] 代表 IAB Executive Administrative 
Manager
发送时间: 2021年11月11日 1:10
收件人: architecture-disc...@ietf.org
抄送: pa...@irtf.org
主题: [PANRG] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01

The IAB will discuss adoption of draft-arkko-iab-path-signals-collaboration-01 
(Considerations on Application - Network Collaboration Using Path Signals) on 
the IAB stream at its meeting on 2021-11-17.

The draft can be found here: 
https://datatracker.ietf.org/doc/draft-arkko-iab-path-signals-collaboration/

The agenda for the meeting will be posted 48 hours ahead of the meeting here: 
https://www.iab.org/wiki/index.php/Agenda

Feedback about this draft can be sent in response to this mail on 
architecture-disc...@ietf.org, or to the IAB directly at i...@iab.org.

___
Panrg mailing list
pa...@irtf.org
https://www.irtf.org/mailman/listinfo/panrg
___
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]

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 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

Re: [alto] Meeting Info for Nov 23, 2021

[kaigao]

Hi Sabine,




OK. Below is the updated agenda:




- Discuss the review of Eric on Unified properties and Performance metrics


- Design sessions for new charter items:

  - ALTO new transport

  - ALTO OAM







Best,

Kai


-Original Messages-
From:"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" 

Sent Time:2021-11-22 23:45:32 (Monday)
To: "kai...@scu.edu.cn" , 
"alto-weekly-meet...@googlegroups.com" , 
"alto@ietf.org" 
Cc:
Subject: RE: [alto] Meeting Info for Nov 23, 2021



Hi Kai and all,

We may also want to allow some time to discuss the review of Erick Vyncke on 
Unified properties and Performance metrics.

Best regards,

Sabine

 

From: alto  On Behalf Of kai...@scu.edu.cn
Sent: Monday, November 22, 2021 4:32 PM
To: alto-weekly-meet...@googlegroups.com; alto@ietf.org
Subject: [alto] Meeting Info for Nov 23, 2021

 

Dear all,

 

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

 

Agenda:

 

- Design sessions for new charter items:

  - ALTO new transport

  - ALTO OAM

 

Bridge:

 

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

 

If anyone wants to present or lead the discussion of other topics, please feel 
free to let me know.

 

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)

[Eric Vyncke (evyncke)]

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" 
, 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 
mailto: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 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

Re: [alto] Meeting Info for Nov 23, 2021

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Hi Kai and all,
We may also want to allow some time to discuss the review of Erick Vyncke on 
Unified properties and Performance metrics.
Best regards,
Sabine

From: alto  On Behalf Of kai...@scu.edu.cn
Sent: Monday, November 22, 2021 4:32 PM
To: alto-weekly-meet...@googlegroups.com; alto@ietf.org
Subject: [alto] Meeting Info for Nov 23, 2021


Dear all,



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



Agenda:



- Design sessions for new charter items:

  - ALTO new transport

  - ALTO OAM



Bridge:



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



If anyone wants to present or lead the discussion of other topics, please feel 
free to let me know.



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]

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 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

[alto] Meeting Info for Nov 23, 2021

[kaigao]

Dear all,




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




Agenda:




- Design sessions for new charter items:

  - ALTO new transport

  - ALTO OAM




Bridge:




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




If anyone wants to present or lead the discussion of other topics, please feel 
free to let me know.




Best,

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

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

[Éric Vyncke via Datatracker]

É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

[alto] Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-alto-unified-props-new-20: 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/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-unified-props-new/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Vijay Gurbani for the shepherd's extended write-up about the
WG consensus (even if not using the usual template).

While the document supports clearly the two address families (IPv4 and IPv6), I
can only regret that the vast majority of examples are for IPv4.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

While the documents is very detailed, I would have preferred to have a generic
introduction of the concepts at the beginning. It also seems to me that part of
the text is repetitive.

-- Section 3.1 --
I am a little puzzled by the use of "TCP/IP network flow" as it mixes up
layers. Also, the "associated 5-tuple" is redundant because TCP has always 6 as
protocol so it is not really a 5-tuple as one is constant.

-- Section 4.6.1 --
The use of "ane" is done before its explanation later in section 4.6.2.

-- Section 5.1.3 --
"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a /128
address.

-- Section 10.4 (and possibly others) --
Please use RFC 5398 when using ASN in examples.

-- Section 10.9 --
Is the JSON reply valid ?

-- Section 13 --
No hard feeling but I find it strange that the acknowledgements section also
includes some affiliations.

== NITS ==

-- Section 10.1 --
RFC 5792 prefers ipv6:::/0 to ipv6:::0/0



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