Re: [alto] BGP-LS as replicated IGP computing and BGP route collection

[Y. Richard Yang]

d (well,
>edge-to-edge) path latency both in IPPM and TEAS – I find it a bit
>suspicious! Nevertheless, if this information was available, it might
>usefully be passed to and processed by an ALTO server. Whether you use
>BGP-LS to collet the information largely depends on where the information
>is, what granularity and churn the information has, and who
>selects/establishes the edge-to-edge paths that you want to report on.
>
>
I share this point. I take the view that ALTO is an information aggregation
service, from wherever information is. For static (propagation) latency,
IGP can carry it as a TE metric (to be interop, adaptive), and we target to
collect it from BGP-LS, if possible, for engineering purposes. We have
recently build an ALTO server on top of a PerfSonar infrastructure, who
collects data also from IPPM work.


>
>1. Computed paths. While the internal workings of routers are not
>standardised, the SPF algorithms used in OSPF and ISIS **are**
>well-known modulo how ECMP is handled. Thus, it seems unnecessary to export
>the results of these computations (the FIB) which is different on each
>node, when this can be easily computed using the RIB. In fact, this is the
>basic assumption of PCE – that so long as you can see the network topology,
>you can compute any path you want between any two points. In general,
>computation is cheap, data export is expensive.
>
> These are very reasonable points, and we are planning to follow this path.
One consideration of collecting FIB directly is that it is more "evolution"
robust. The computation logic can continue to evolve and be distributed at
multiple points. To know what is computed and installed, collecting the
info directly, by a standard approach, appears to be more robust, for an
abstraction service (of what has been done) such as ALTO and maybe
other services such as control plane verification. Data export is indeed
expensive and hence should be a major consideration in such a route state
(RS) protocol, if designed. Make sense?

Thank you so much!
Richard


>
> Cheers,
>
> Adrian
>
>
>
> [1] Times change, and foundational engineering principles do not
> necessarily remain untouched.
>
>
>
> *From:* Y. Richard Yang 
> *Sent:* 22 July 2023 23:44
> *To:* Adrian Farrel ; Randriamasy, Sabine (Nokia -
> FR) ; a...@cs.yale.edu; stefano
> previdi 
> *Subject:* BGP-LS as replicated IGP computing and BGP route collection
>
>
>
> Hi Stefano, Adrian,
>
>
>
> I have become increasingly more appreciative of the BGP-LS work started by
> your RFC7752.
>
>
>
> After close to 9 years, we start to see some deployments. One main hurdle
> of ALTO deployment I see is the difficulty to obtain alto information, such
> as basic end-to-end delay maps. Hence, the increasing deployment of BGP-LS
> is a great catalyst.
>
>
>
> But I have two questions:
>
> 1. Is there evaluation/report on whether BGP-LS has enough info to
> replicate the computed paths by IGP such as OSPF and IS-IS? Using BGP-LS
> collection as topology for TE does not require the consistency between IGP
> computed route, but as a compact model does.
>
>
>
> 2. What is your reaction on using BGP(-LS) to collect computed routes that
> includes all routing processes from each router? I see scalability is a
> potential objection in that the information size is number of routers times
> number of prefixes, where topology collection does not have such
> multiplication. But this depends on the details and we may investigate
> optimizations. Is there any related investigation?
>
>
>
> Thank you so much!
>
> Richard
>
> --
>
> Richard
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Tuesday 07/18/2023

[Y. Richard Yang]

ivacy-Policy.pdf>
> .
>
> Informamos que o responsável pelo tratamento dos seus dados é a entidade
> do Grupo Telefónica vinculada ao remetente, a fim de manter o contato
> professional e administrar a relação estabelecida com o destinatário ou com
> a entidade à qual esteja vinculado. Você pode entrar em contato com o
> responsável do tratamento de dados e exercer os seus direitos escrevendo a
> privacidad@telefonica.com. Você pode consultar informação adicional
> sobre o tratamento do seus dados na nossa Política de Privacidade
> <https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Fwd: New Version Notification for draft-yang-alto-multi-domain-03.txt

[Y. Richard Yang]

FYI. Any comments or suggestions are greatly appreciated.

-- Forwarded message -
From: 
Date: Mon, Jul 10, 2023 at 9:20 PM
Subject: New Version Notification for draft-yang-alto-multi-domain-03.txt
To: Y. Richard Yang , Annie Gu , Danny
Lachos , Ingmar Poese , Jordi Ros
Giralt , Mario Lassnig 



A new version of I-D, draft-yang-alto-multi-domain-03.txt
has been successfully submitted by Y. Richard Yang and posted to the
IETF repository.

Name:   draft-yang-alto-multi-domain
Revision:   03
Title:  ALTO Multi-Domain Use Cases and Services
Document date:  2023-07-10
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/archive/id/draft-yang-alto-multi-domain-03.txt
Status:
https://datatracker.ietf.org/doc/draft-yang-alto-multi-domain/
Html:
https://www.ietf.org/archive/id/draft-yang-alto-multi-domain-03.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-yang-alto-multi-domain
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-yang-alto-multi-domain-03

Abstract:
   Application-Layer Traffic Optimization (ALTO) provides means for
   network applications to obtain network information.  Although ALTO is
   inherently multi-domain, in that the ALTO server representing the
   network and the ALTO client requesting the network information belong
   to different trust domains, there are more general cases where the
   path from the source and the destination spans multiple autonomous
   networks, which we call multi-domain settings.  This document first
   gives three multi-domain use cases, and the challenges to address the
   challenges.  It then gives a brief update on the implementation
   solutions that we explored to address the challenges.





The IETF Secretariat


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

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

Hi Danny, Luis, Qin,

Very interesting discussions on BGP communities and ALTO network maps.

To better understand the discussion, can we say that there are two settings
or models:
1. ALTO on BGP (Bottom Up)
Given BGP model (the prefixes and their associated attributes announced by
BGP communities). We do not modify this BGP model (i.e., we do not change
the prefixes announced, we do not add/remove communities announced), and we
derive ALTO models on top. For example, assume that there are multiple BGP
routers, and then ALTO can combine the views of these routers to produce a
single view. I feel that this is the essence of Danny’s proposal.

2. ALTO driven BGP (Top Down)
There is info that ALTO need, for example, to derive the cost metric for a
given cost map or ECS. The info carried by BGP is driven (at least
modified) by ALTO.

It looks that the question by Danny uses more on 1, and the example by Luis
will use more on 2. They sure can be combined. Make sense?

Richard

On Sun, Jul 9, 2023 at 11:39 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi Qin, Danny,
>
>
>
> Thanks for your questions and apologies for the late response.
>
>
>
> Certainly, the way in which BGP Communities can be handled is a matter of
> development with ideas / insights from the working group.
>
>
>
> As stated in the version -01 to be submitted (available here
> https://github.com/luismcontreras/alto-bgp-communities), I do foresee the
> following way of handling BGP Communities:
>
>
>
>- In situations where a BGP Community and an ALTO PID scope the same
>grouping of prefixes, leveraging BGP Communities simplifies network
>operations by using an existing identifier for the purpose of retrieving
>ALTO information.
>
>
>
>- In situations where the purpose is to retrieve ALTO information
>applicable to a superset of PIDs, a BGP Community can be defined in order
>to group the prefixes of all those PIDs.
>
>
>
>- In situations where the purpose is to retrieve ALTO information
>applicable to a subset of prefixes across multiple PIDs, a BGP Community
>can be defined in order to group the subset of prefixes of all the PIDs.
>
>
>
>
> In summary, what I would expect is to have new network maps working with
> the concept of BGP Community as object. The prefixes associated with each
> BGP Community will be defined at BGP level. I’m considering for this
> specific operator defined communities, for instance those that have a
> geographical meaning (e.g., prefixes in Region-1 vs Region-2, commonly
> defined to being associated to peering point 1 vs 2).
>
>
>
> Hope this clarifies the questions. Anyway, more discussions are needed in
> the WG for well defining how to work with Communities, as well as to
> identify limitations, if any.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Qin Wu 
> *Enviado el:* jueves, 6 de julio de 2023 4:18
> *Para:* Danny Lachos ; LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>; Y. Richard Yang <
> y...@cs.yale.edu>; IETF ALTO 
> *Asunto:* RE: [alto] Topic B - maintenance of ALTO protocol // RE: June
> 20, 2023 meeting minutes and discussion working links
>
>
>
> Hi, Danny:
>
> BGP community can be seen as a tag attached to the BGP routes exchanged
> between two BGP peers.
>
> It is interesting to see ALTO network map can be generated based on
> BGP-communities, two questions I want to ask here:
>
>1. We have many common BGP communities, e.g., local AS community,
>route target community, route origin community, do you think all these
>communities can be used to generate network map
>2. For network map, we usually map IP addresses to PIDs, e.g.,
>
>
>
>"network-map" : {
>
>  "PID0" : { "ipv6" : [ "::/0" ] },
>
>  "PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
>
>  "PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
>
>  "PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
>
>}
>
>   So when we introduce communities, do you think such mapping should
> be modified, replaced? What format will looks like?
>
>   e.g., should establish the mapping between PIDs and community or
> should we define the network map other than ipv4/ipv6 network map?
>
>
>
> -Qin
>
> *发件人**:* alto [mailto:alto-boun...@ietf.org ] *代表 
> *Danny
> Lachos
> *发送时间**:* 2023年7月5日 15:59
> *收件人**:* LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contre

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

Hi Luis, Qin,

Good discussions. I see several good points:
-  "... explore how node, link information combing with next hop
information, inter-AS link information carried in BGP-LS is transformed
into network map, cost map, property map, etc, performance data which is
related to cost map."
- "... operators use BGP communities quite often as mechanism for applying
policies and determining certain behaviors on the IP addresses grouped in
the form of communities. This seems quite useful as well at the time of
exposing associated information (metrics, topology, etc) as enabled by
ALTO." In particular, we see BGP as a framework for policy checking and
recursive information propagation with policy control.

Given above, here are a few discussion points. The focus is on supporting
ALTO deployment; that is, how to obtain ALTO-needed information from BGP as
a carrier.

- Use BGP communities to propagate ALTO cost metrics, for subnet, as
a generalization of BGP propagating AS PATH
One main data source issue in ALTO is to compute the total cost of a cost
metric end-to-end, from a source to a given destination. Such information
can be propagated using BGP denoted as BGP communities. The propagation
will be recursive (cascading) to take advantage of BGP. BGP policies can be
used to adjust the propagated values. Ideally, the information is between
on-path BGP routers to achieve well-defined semantics:
- the BGP node of the destination AS announces the initial cost metrics
using BGP communities to a subnet prefix;
- the metrics are sent upstream to the next hop BGP peer, which applies
policy to decide, for each metric and each upstream, how to compute the
update aggregated metric (AS path is a special case of pre-pending ASN),
whether/when the info can be propagated (export policy).

Looking at the current set of ALTO performance metrics, we can see that
hoop count as additive; one-way delay, roundtrip delay, and delay variation
as additive as a starting point; residual bw, available bw as min. The tput
metric can be harder to compute and can be a topic for further
investigation.

There can be concerns for the model, both on protocol (scaling) and on
content (privacy). For protocol scaling, the information will be more
dynamic than AS path, and hence there is the concern of overhead. We can
limit the information for chosen subsets; for content, BGP policies appear
to be a great tool, but we should look into the details.

- Use BGP community from upstream to downstream to support cascading ALTO
I always feel that BGP is the right place to allow an upstream peer to
notify a downstream peer whether the downstream's announcement (proposal)
is accepted. This can be a good protocol design than depending on inference
or measurements (e.g., see which inter-AS links carry the traffic). Is it
already proposed? If so, such info can be exposed to ALTO to allow building
a more complete ALTO system.

These comments are particularly interesting:
- "... need to maintain these two separate sessions to create the network
and cost map for BGP community reachability"
- "... a BGP community can span more than one physical location, thus
probably new kind of cost metrics need to be elicited for characterizing
the cost map"

For the second case, how about cost vectors providing only partial order?
That is, we do not aggregate the raw metrics (e.g., routingcost) if it is
not possible (e.g., the two physical locations do not have a single
policy), and provide the vector; it is a bit like BGP path has SET. Make
sense?

Richard


On Sun, Jul 9, 2023 at 11:48 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi Richard, Qin,
>
>
>
> Apologies for the late answer.
>
>
>
> In the particular case of Communities, we are identifying some logical
> grouping of prefixes from end-users attached to the operator’s network.
> This is done within conventional BGP sessions. On the other hand, with
> BGP-LS we are obtaining the topological information that allows to derive
> the view of how those prefixes can be reached.
>
>
>
> In summary, we need to maintain these two separate sessions to create the
> network and cost map for BGP community reachability. This is an interesting
> problem since a BGP community can span more than one physical location,
> thus probably new kind of cost metrics need to be elicited for
> characterizing the cost map. I think this can be an interesting work to be
> discussed by the WG in future work.
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* Qin Wu 
> *Enviado el:* jueves, 6 de julio de 2023 4:52
> *Para:* Y. Richard Yang ; LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com>
> *CC:* IETF ALTO 
> *Asunto:* RE: [alto] Topic B - maintenance of ALTO protocol // RE: June
> 20, 2023 meeting minu

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

On Tue, Jun 27, 2023 at 8:33 AM Y. Richard Yang  wrote:

> Hi Luis,
>
> Thank you so much for starting this thread on Topic B. I feel that this is
> a crucial topic for the WG to investigate. Please see below.
>
> On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com> wrote:
>
>> Hi all,
>>
>> Related to Topic B on maintenance of ALTO, as a way of summary of what
>> has been discussed during the last weeks, we could have two major
>> sub-topics:
>>
>> 1/ extension of ALTO to consider operational simplicity. Here fits the
>> proposal of introducing BGP communities in ALTO. The rationale is that
>> operators use BGP communities quite often as mechanism for applying
>> policies and determining certain behaviors on the IP addresses grouped in
>> the form of communities. This seems quite useful as well at the time of
>> exposing associated information (metrics, topology, etc) as enabled by
>> ALTO. An initial draft can be found here:
>> https://github.com/luismcontreras/alto-bgp-communities
>>
>> The plan is to generate version -01 for IETF 117.
>>
>

> I like this subtopic! I have adopted a view that ALTO should be divided
> into 2 layers: a concept/abstraction layer and a transport layer built on
> top of the concept layer. I feel that there is great work validating the
> concept layer, for example, the concepts of distance, ranking, say in the
> flow director, padis work. For transport later, the WG can be flexible and
> provide multiple transport mechanisms. BGP communities are an excellent,
> well defined framework to serve as a transport (of both existing alto
> concepts/abstractions) and also existing networking abstractions). Good
> direction.
>

To be specific, I think it will be a worthwhile effort to look into
BGP-ALTO; that is, how to use BGP to encode, transport and update ALTO
basic information. It can be considered a BGP vertical slice, with BGP-LS
as the lower lower layer. Make sense? I will add some more details to the
doc.

Talk to many of you soon.

Richard

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

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

Hi Luis,

On Tue, Jun 27, 2023 at 8:43 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi Richard,
>
>
>
> Thanks for your comments.
>
>
>
> Just a small comment on security. Certainly we are addressing two
> dimensions in ALTO regarding security, at least from my view. One is the
> security of ALTO itself, which I understand is part of maintenance (topic
> B). And the other one is the enablement of new services as the trusted
> networking case, as presented by Ayoub (topic C). This is at least my
> understanding, both are complementary and equally interesting to work on,
> for sure.
>

Great clarification. So the first aspect is the focus of Topic B and the
second aspect is in Topic C. Right?

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

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

Hi Luis,

Thank you so much for starting this thread on Topic B. I feel that this is
a crucial topic for the WG to investigate. Please see below.

On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi all,
>
> Related to Topic B on maintenance of ALTO, as a way of summary of what has
> been discussed during the last weeks, we could have two major sub-topics:
>
> 1/ extension of ALTO to consider operational simplicity. Here fits the
> proposal of introducing BGP communities in ALTO. The rationale is that
> operators use BGP communities quite often as mechanism for applying
> policies and determining certain behaviors on the IP addresses grouped in
> the form of communities. This seems quite useful as well at the time of
> exposing associated information (metrics, topology, etc) as enabled by
> ALTO. An initial draft can be found here:
> https://github.com/luismcontreras/alto-bgp-communities
>
> The plan is to generate version -01 for IETF 117.
>
> I like this subtopic! I have adopted a view that ALTO should be divided
into 2 layers: a concept/abstraction layer and a transport layer built on
top of the concept layer. I feel that there is great work validating the
concept layer, for example, the concepts of distance, ranking, say in the
flow director, padis work. For transport later, the WG can be flexible and
provide multiple transport mechanisms. BGP communities are an excellent,
well defined framework to serve as a transport (of both existing alto
concepts/abstractions) and also existing networking abstractions). Good
direction.

>
>
> 2/ security aspects of ALTO. This has been discussed in both one of the
> interim meetings (see
> https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00)
> and one ad-hoc discussion meeting (
> https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/).
> The rationale for this activity is to improve the security around the
> deployment and operation of ALTO in production networks. As commented
> during the interim, there are a number of security issues documented so
> far, like:
>
>- A high-level discussion of security issues in the ALTO problem
>statement [RFC5693]
>- Unwanted information disclosure risks, as well as specific
>security-related requirements in the ALTO requirements document [RFC6708].
>- Issues related ALTO server discovery in [RFC7286]
>- Identified cases for ALTO deployments in [RFC7971]
>- Security considerations in the remaining RFCs
>
> However, new security concerns emerge from deployments, such as:
>
>- Obfuscation of PIDs, and the handling of them in scenarios with
>multiple ALTO clients
>- Mechanisms for isolation of the ALTO server from direct client
>interaction
>- Secure retrieval of information from external components (e.g.,
>probes, etc)
>- etc
>
> A potential first step could be to document these new security
> considerations and then concentrate on those not solved representing
> relevant threats in ALTO operation.
>

This is also a great topic for this thread. It can benefit greatly with
aspects by Ayoub and team as well.

Richard

> There could be other relevant topics related to the maintenance of ALTO
> part from the two commented above.
>
>
>
> Any further ideas on this respect?
>
>
>
> Of course for those interested on the topics above, please comment.
>
>
>
> Thanks in advance
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> *De:* alto  *En nombre de * Y. Richard Yang
> *Enviado el:* miércoles, 21 de junio de 2023 1:47
> *Para:* IETF ALTO 
> *Asunto:* [alto] June 20, 2023 meeting minutes and discussion working
> links
>
>
>
> Hi all,
>
>
>
> As suggested by Ayoub, Jordi and others during the weekly meeting today,
> starting from today, the note taker will not only update the meeting
> minutes page (
> https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md),
> but also provide a text summary and comments, if appropriate, on the
> meeting. So below are my quick comments and the full meeting minutes are
> below; the archive is at the link above.
>
>
>
> Regarding comments, the most important item that I, as a note taker, take
> away is the wonderful discussion about how to organize future work
> discussions. In particular, the participants divided the potential work
> into 4 areas, and created 4 github issues. We also created a common Google
> doc to allow systematic write up. The links to them are below.
>
>
>
> In particular, the four areas and their coordin

Re: [alto] June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

Hi Jordi,

Will we use email thread for each topic as well? I am writing up a document
for some aspects of Topic A and am eager to post :-)

Richard

On Wed, Jun 21, 2023 at 7:34 AM Jordi Ros Giralt 
wrote:

> Hi all,
>
> Many thanks Richard for the great notes and summary of our call yesterday.
>
> Following up on the below plan, I initiated the conversation for topic A
> under this thread:
> https://mailarchive.ietf.org/arch/msg/alto/nSBb2fJwwEEEeZ-Xxw-OmHhJdTs/
>
> Please use this thread to directly express your opinions on topic A. Other
> group members will be initiating similar threads for the other topics.
>
> I have also updated the root document on ALTO future work to include the
> latest conversations about each of the topics:
> https://docs.google.com/document/d/1rpziU7NZEE8f84XkJSjMhEIHUA5G7rXkGB5c_7UFxUY/edit?usp=sharing
>
> Thanks,
> Jordi
> ----------
> *From:* alto  on behalf of Y. Richard Yang <
> y...@cs.yale.edu>
> *Sent:* Wednesday, June 21, 2023 1:47
> *To:* IETF ALTO 
> *Subject:* [alto] June 20, 2023 meeting minutes and discussion working
> links
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> Hi all,
>
> As suggested by Ayoub, Jordi and others during the weekly meeting today,
> starting from today, the note taker will not only update the meeting
> minutes page (
> https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md),
> but also provide a text summary and comments, if appropriate, on the
> meeting. So below are my quick comments and the full meeting minutes are
> below; the archive is at the link above.
>
> Regarding comments, the most important item that I, as a note taker, take
> away is the wonderful discussion about how to organize future work
> discussions. In particular, the participants divided the potential work
> into 4 areas, and created 4 github issues. We also created a common Google
> doc to allow systematic write up. The links to them are below.
>
> In particular, the four areas and their coordinators are:
> - A: Integration of data sources and their exposures; coordinator: Jordi,
> Luis and Kai
> - B: Maintenance of ALTO protocol; coordinator: Luis, Richard
> - C: Security and trust; coordinators: Ayoub, Junichi, Motoyoshi
> - D: New architectural extensions; coordinators: Roland and Sabine
>
> We sure can adjust the coordinators. So so, please let me know, and we can
> adjust the page. The plan is that the coordinators will closely with the
> chairs (Qin and Med) to make concrete progress. The coordinators will kick
> off the discussions.
>
> Richard as note taker on June 20, 2023
>
>  Meeting Minutes Text 
>
> *IETF, ALTO Meeting: June 20, 2023*
>
> *Agenda:*
>
>- Transport and OAM documents
>   - Transport:
>   https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues
>- OAM: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues
>- ALTO Future Work:
>https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/
>
>
> https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
>- Preps for IETF 117:
>   - Drafts and presentations that the ALTO group plans to work on
>   - Agenda
>- New revision of Green Networking Metrics draft in opsawg:
>https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/
>
> *Minutes*
>
> *Note taker: Richard
>
>-
>
>Charter documents: transport and OAM updates
>- OAM: Jensen and Med had a discussion on the draft and submit the
>   revision to IESG. The document is now waiting for AD review.
>   - Transport: Richard sent a note to Martin Thompson, to provide the
>   justification on introducing server push using PUSH PROMISE. It includes
>   two basic reasonings: lower load, and the feature is optional; Kai 
> updated
>   that Med sent two pull requests and sent the latest version for AD 
> review,
>   and wait for updates.
>-
>
>Updates on future work on ALTO
>-
>
>   Overview: Jordi started with an update on the planning: Please
>   follow the ongoing conversation on the WG mailing list initiated by 
> Sabine,
>   engaged by Jordi and Luis; the WG welcomes conversations by all; please
>   socialize the ideas; leadership is important and please take ownership;
>   this WG meets each week, and we do not know any other IETF WG that meets
>   each week, but because we meet each week, we do not use the mailing 
> list,
>   which may appear to be inactive by those not a

[alto] June 20, 2023 meeting minutes and discussion working links

[Y. Richard Yang]

  -

  Topic D:
  - GitHub: #51 <https://github.com/ietf-wg-alto/wg-materials/issues/51>
 - Coordinator: Luis, Jordi
  -

  Discussion Google doc:
  -
 
https://docs.google.com/document/d/1rpziU7NZEE8f84XkJSjMhEIHUA5G7rXkGB5c_7UFxUY/edit?usp=sharing
  -

  Goals: Enabling conversations and concrete documents (compute, edge
  service, etc), need to focus; real good way to make progress is
  internet-draft (ID) as ground truth, from dynamic to stable,
with focus on
  writing drafts for concrete results).



-- 
-- 
 =========
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] draft-ietf-alto-oam-yang review (Part 1)

[Y. Richard Yang]

Hi Jensen, all,

Thank you for authoring the OAM document. It clearly is a massive effort on
an important task that helps with ALTO development. In the first part of
this review, I will focus on early text and structure. I will review the
yang model details soon.

High-level structure: My understanding of the model structure is that it
consists of (Figure 2)
- a set of alto clients
- an alto server

It helps, to me, that Figure 2 gives all of the top-level structures; that
is, it lists the complete first-level structures under alto-server, instead
of using ...

In particular, the structure appears to be a bit interleaved. For example,

- It looks that the access control is somehow flattened into the top
alto-server container (Figure 2): auth-client and role
Should they belong to a sub structure that defines access control? Such a
contained structure may allow easier replacement/plug and play?

Similar to access control, sever level op also appears to be
flattened (Figure 4). For example, why is cost-type in the top level?

In general, what is the principle to define the current container
structure? It helps to clarify.

 Some details 
Abs/Intro: I appreciate that the document follows RFC6291 when using the
terms, Operations, Administration, Maintenance, Management, OAM, and O
But these terms are defined for the context of managing a network, not a
service such as ALTO. It helps to clarify/motivate why this document can
follow RFC6291. It looks like this document uses only O and if so, it
helps to make clear that this is the case.

Abs: “The operator can use these data models to set up an ALTO server, ..”
=> “The operator of an ALTO server can use these data models to set up the
ALTO server, “ More generally, it helps to give an order of the workflow.
For example, the words “set up” and “create” appear to be redundant. Also,
the abstract mentions sever but the document also has client.

Intro: “This document defines a YANG data model”, but the title and abs say
models. The rest of the 1st paragraph uses one model. It helps to be
consistent in saying models or model. You may search the document and find
model vs models and be consistent (e.g., first para of 4.2). It might be
that a model consists of multiple modules.

Intro: “implementation-agnostic“. It helps to make clear the list in
Section 4.1 early.

Intro: “... the design will also be extensible for future standard
extensions.” This is a hard-to-defend statement because an extension could
be a major change. How about not making this statement?

Overall suggestion: reorganize paragraphs 2,3,4.

Sec. 3.1 “names of data nodes and other data model objects
   are often used without a prefix, as long as it is clear from the
   context in which YANG module each name is defined.  Otherwise, names
   are prefixed using the standard prefix associated with the
   corresponding YANG module”
=> // use singular
“the complete name of a data node or data model object
 includes a prefix, which indicates the YANG module in which the name is
defined.
 We omit the prefix when the YANG module is clear from the
   context;  otherwise, we include the prefix.
   The prefixes indicating the corresponding YANG modules are shown in
Table 1”

Sec. 3.2 3.3: Does Table 1 miss a few prefixes, for example, ncc?

Sec. 4.1: “Functionality/capability configuration of ALTO services.” =>
“Configuring functionality/capability of ALTO services.” to be consistent
with the other items

Sec 4.4: “Figure 1 shows a reference architecture for the ALTO server
 implementation.” => Figure 1 shows a reference architecture for an ALTO
server implementation.” ?

Sec. 5.1: Thanks for providing a reference architecture. Two quick
comments. (1) It helps to say a few words about what a client is and hence
one may get a sense of the client id it. Is it a running instance or a
template?  (2) An immediate reaction is that a “data source” can be another
alto client, for multi-domain integration.

Sec. 5.3 “The ALTO server instance contains a set of data nodes
server-level operation and management for ALTO that are shown in Figure 4.”
Fragmented sentence?

Sec. 5.3.2 shonw
Sec. 5: ird -> IRD in text because it is an acronym?
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Discussion on the future of ALTO WG

[Y. Richard Yang]

Hi Sabine,

On Thu, Mar 23, 2023 at 8:58 AM Sabine Randriamasy (Nokia) <
sabine.randriam...@nokia-bell-labs.com> wrote:

> Hi Med, Qin and ALTO WG
>
>
>
> Thanks a lot for initiating this discussion and your options proposal.
>
>
> https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
>
>
>
> I definitely prefer Proposal #3: Support ALTO extensions for the new
> industry needs
>
>
>
> Thanks a lot to Jordi's insights on this option, that I share. ALTO WG may
> also want to work on abstraction of compute metrics and exposure, in
> relation to other IETF WG that would look at these matters. As a previous
> example, draft-ietf-alto-performance-metrics-28 (in RFC Ed queue) was done
> in coordination with the IPPM WG.
>

Thank you so much for this positive, collaboration motivation suggestion.
Given the detail, it appears Option 3 can be "Support ALTO extensions for
the new industry *and other WG* needs", but ultimately it should be driven
by industry need and I am hence also fine with just the current title.

The important piece by Sabine which I want to single out is "To add another
motivation for option 3, it is to be noted that CATS in its current charter
is mandated to produce *Informational* documents while ALTO is aiming at
standardized compute & network infrastructure exposure." So this can be a
good collaboration opportunity as well, in addition to separation into the
networking domain and application domain in the computing integration use
domain.

Richard

>
>
> Kind regards,
>
> Sabine
>
>
>
> *From:* alto  *On Behalf Of *
> mohamed.boucad...@orange.com
> *Sent:* Thursday, March 23, 2023 8:12 AM
> *To:* Jordi Ros Giralt ; Qin Wu  >
> *Cc:* alto@ietf.org
> *Subject:* Re: [alto] Discussion on the future of ALTO WG
>
>
>
> Hi Jordi, all,
>
>
>
> Only some logistic comments, not reacting to any expressed views so far:
>
>
>
>- We created a page at
>
> https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
>to track the various proposals (yours is posted there), challenge them,
>enrich them, add rebuttals, etc.
>- For your logistic comment, we organized on purpose an interim
>meeting to offload the IETF#116 agenda and let other I-Ds be presented and
>discussed. We scheduled 4 other interims till end of May. We really need
>some focus at this stage.
>
>
>
> Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Jordi Ros Giralt 
> *Envoyé :* jeudi 23 mars 2023 00:13
> *À :* Qin Wu ; BOUCADAIR Mohamed INNOV/NET <
> mohamed.boucad...@orange.com>
> *Cc :* alto@ietf.org
> *Objet :* Re: [alto] Discussion on the future of ALTO WG
>
>
>
> Hi Med, Qin,
>
>
>
> Here is my feedback to your analysis below.
>
>
>
> I would like to start with a note. The ALTO team has brought (and
> continues to bring) a lot of positive energy (development of RFCs,
> deployments of the standard at major carriers and new deployments that are
> in the making, running code via the development of the open source project
> OpenALTO, consistent participation on IETF hackathons usually with multiple
> parallel projects/demos, chairing important forums such as SIGCOMM NAI to
> incorporate feedback into the WG from the broad spectrum of industry and
> academic players, etc.), but it is also true that much of the (even larger)
> potential energy of the group has been locked for quite some time as the
> group has not been allowed to discuss the new critical topics that we want
> to bring from our industry needs. We've all being waiting for this moment,
> to be able to discuss the new topics and unlock yet another level of
> positive energy into the IETF; and so, it is at the minimum surprising that
> the only two options being proposed are either (1) recharter with just a
> focus of working on protocol maintenance or (2) close the WG and move our
> current work to other WGs or RGs.
>
>
>
> I have two broad comments, one on the proposed options and another one on
> the logistics to make a proper decision.
>
>
>
> On the proposed options:
>
> 
>
> I would like to suggest adding a 3rd proposal, which I believe is what
> much of us have been working for, for quite some time:
>
>
>
> # Proposal #3: Support ALTO extension for the new industry needs.
>
>
>
> ## Rationale:
>
>- Many I-Ds have been proposed describing the importance of leveraging
>ALTO key core architecture to enable the new industry needs, where close
>cooperation between the application and the network is critical.
>- Allowing these extensions would enable the group to grow and unlock
>its true potential, also attracting other industry players that have been
>writing ALTO I-Ds, but not fully joined us yet because their proposals were
>tagged as being out of the scope for the current charter.
>- Lots of positive energy and determination in the WG, as we
>understand the potential positive impact (better application 

[alto] ALTO deployment wiki page updates

[Y. Richard Yang]

Hi all,

Some of us have made additional updates to the ALTO deployment wiki:
https://wiki.ietf.org/en/group/ALTO/deployment

Any feedback and suggestions will be appreciated.

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

Re: [alto] Discussion on the future of ALTO WG

[Y. Richard Yang]

Hi Med, Qin,

Thank you for initiating the discussion of this important topic.

At a high level, my understanding of the proposed decision-making
methodology is the following: let's have an assessment (it is called
rational in the email and I will use the same term) of the current state
and potential state of the WG and its work, and then make decisions. It is
important that (1) the set of rationals is well specified and (2) the
decision for a given rational is coherent with the rational.

Personally, I will use a different methodology: identify the set of actions
(decisions), identify their pros and cons, and pick the best action, in the
interest of IETF in specific and the Internet in general. First, I see 3
actions: (a1) maintaining the WG without opening much new work;
(a2) maintaining the WG with new work; and (a0) concluding the WG.

So far, we are following a1, and let me give some quick comments on the
pros and cons of a0-a2. I will then switch to following the methodology of
the email.

a0: pros: reduce the number of meetings at IETF, reduce the number of
people who attend IETF, reduce the workload on IESG/AD; maybe having fewer
bad drafts/standards; cons: many of us believe that ALTO is an important
component of the Internet architecture, and the opportunity is missed;
multiple active participants of IETF will just leave IETF and focus on
other venues.

a1: pros: focus the efforts of the WG; cons: it substantially limits the
energy of the WG, with each meeting emphasizing that only chartered items
can be discussed. Historically, it pushed BGP-LS away from the WG with much
resentment; recently, it is pushing computing-aware away, edge-aware away
...

a2: pros: increase the interests/energy of the WG, designing a more
coherent framework; cons: diversion of efforts

It should be obvious that I support a2, and I see clear values to the IETF
and the Internet.

Now let me follow the methodology in the email, and follow the request to
discuss the rationals. Let me first repeat the rationales and decisions and
add labels for ease of reference.

R1: R1.1: Many I-Ds are being proposed to ALTO; R1.2 Some
deployments/products are being disclosed. R1.3 Having a referent WG is a
signal that the IETF is ready to support operations and fix
flaws/limitations that will be reported. R1.4 ALTO integration
complications were out of the scope. R1.5 Documenting those with a set of
deployment choices may be a helper for other deployments. R1.6 There is
constant engagement and dedication of a core team to deliver ALTO specs.
D1: D1.1 Recharter the WG with a focus on ALTO maintenance and integration
with data sources. D1.2 Dedicated YANG modules will be produced.

Comment: I do not see why R1.4 is supported. Further, I do not see
clear logic for the decisions to be derived. For example, It looks to me
that D1.1 and R1.1 do not match.

I have more minor comments on R1->D1, but let me focus more on R2->D2.

R2: R2.1 Some of the proposed ALTO work is research-oriented (PANRG, would
be more appropriate for some items), while other may be conducted in new
WGs (e.g., CATS). R2.2 Some of the key foundations of ATLO might not be
valid after 15 years. R2.3 Closing the WG is not a failure, but a sign of
ALTO specification maturity. R2.4 Revitalizing the ALTO effort is thus
needed.

D2. D2.1 Consider closing ALTO right after the completion of OAM/Transport
items. D2.2 Move ALTO maintenance to TSVWG. D2.3 Use the ALTO/TSVWG mailing
lists to socialize deployment experience. D2.4 Based on the maintenance
that might be shown in TSVWG and shared deployments, reassess the interest
of the community in enriching ALTO with additional features by organizing a
formal BoF.

Comments:
- I agree with R2.1, but if there is one thing I sincerely feel, it is that
the core team of WG focuses their efforts on non-research, but engineering,
for the interest of the WG. Also, some are research-oriented does not imply
all are research-oriented.
- I am not sure about the meaning of R2.2. ALTO provides some of the
simplest abstractions. It will be great if we can list those foundations
which are not ready.

As I said above, I found the action list D2 not ideal (see cons of a0).

Overall, I want to add, in particular, to those fellow ALTO core team
members and those who work on ALTO, please do not take this discussion with
only negativity. It is a dedicated team who volunteers their time to IETF
and designs protocols to make the Internet better. This team follows the
advice and focuses on deployment-driven design. It is sad that the efforts
are not met with more appreciation, encouragement and positivity, but such
discussions. Many of us strongly believe in this work and we will surely
work together.

Thanks,
Richard



On Wed, Mar 22, 2023 at 4:09 AM  wrote:

> Hi all,
>
>
>
> As the WG is about to finalize the last chartered items, we would like to
> have a discussion on the future of the WG with all of you. We will also
> have a slot during the IETF#116 

[alto] Fwd: New Version Notification for draft-yang-alto-multi-domain-01.txt

[Y. Richard Yang]

Hi WG,

We posted a first version of a draft to discuss the issues and potential
solutions of ALTO in multi-domain settings. Any comments and suggestions
will be greatly appreciated. We will follow up with more updates soon.

Thanks!
Richard

-- Forwarded message -
From: 
Date: Mon, Mar 13, 2023 at 6:44 PM
Subject: New Version Notification for draft-yang-alto-multi-domain-01.txt
To: Y. Richard Yang , Mario Lassnig 

A new version of I-D, draft-yang-alto-multi-domain-01.txt
has been successfully submitted by Y. Richard Yang and posted to the
IETF repository.

Name:   draft-yang-alto-multi-domain
Revision:   01
Title:  ALTO Multi-Domain Services
Document date:  2023-03-13
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-yang-alto-multi-domain-01.txt
Status:
https://datatracker.ietf.org/doc/draft-yang-alto-multi-domain/
Html:
https://www.ietf.org/archive/id/draft-yang-alto-multi-domain-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-yang-alto-multi-domain
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-yang-alto-multi-domain-01

Abstract:
   Application-Layer Traffic Optimization (ALTO) provides means for
   network applications to obtain network information.  In the
   definitions of ALTO services ([RFC7285] and existing extensions),
   there is no requirement on whether the source and the destination
   endpoints must belong to the same autonomous network, which is a
   single-domain setting, or they can belong to different autonomous
   networks, which is a multi-domain setting.  This document explains
   problems of realizing ALTO in multi-domain settings and then presents
   3 potential solutions to realize ALTO multi-domain services.





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

[alto] Multi-domain use case discussion

[Y. Richard Yang]

Hi All,

With the interim meeting behind us, I was suggested to start the discussion
of the multi-domain use case, which is a use case driven by a real setting.

Details: A motivation use case of multi-domain ALTO is the LHCONE setting,
which is an L3VPN consisting of multiple networks [1]. Given a set of
endpoint nodes N (e.g., remote storage elements), and their connectivity,
which is a set E of selected source-destination pairs (s, d) in NxN, we can
define a multi-domain cluster as a set of autonomous systems formed by (1)
the autonomous systems containing the endpoints; and (2) the autonomous
systems on the path for those for an (s, d) in E.

Both the transport scheduling system (FTS) and the transport orchestration
system (Rucio) can benefit from a network view of a multi-domain cluster.
For example, FTS can use the mapping (s, d) -> path to compute the
accounting of total traffic volume on a given link; and Rucio can use (s,
d) -> path metric to select the source with the lowest distance path, when
there are multiple potential sources.

The current ALTO protocol is designed more for a single-domain setting, and
hence needs extensions to allow the stitching of information from multiple
ALTO servers representing the member autonomous systems (AS) in a
multi-domain cluster. For example, the source AS can have the global path
vector, but it is abstracted to the AS level. Hence, it needs a recursive
query process to reconstruct the finer-grain metrics (beyond the AS path
metric) of the path from the source to the destination. There can be
multiple southbound implementations, e.g., extension to BGP (e.g., flow
BGP) and also the extension of the ALTO northbound querying process. It
needs also to address the issue of incremental deployment.

Hence, a short paragraph describing the problem is:
Design ALTO multi-domain queries to compute the aggregated path metrics
from a given source to a given destination in a multi-domain cluster.

[1] https://twiki.cern.ch/twiki/bin/view/LHCONE/LhcOneMaps
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IPR Poll: draft-ietf-alto-new-transport

[Y. Richard Yang]

Hi Med, all,

Same from me: I am not aware of any IPR related to
draft-ietf-alto-new-transport.

Thanks,
Richard

On Mon, Feb 27, 2023 at 10:07 AM  wrote:

> Hi,
>
>
>
> I am not aware of any IPR related to draft-ietf-alto-new-transport.
>
>
>
> Best Regards
>
>
>
> Roland
>
>
>
>
>
> *Von:* mohamed.boucad...@orange.com 
> *Gesendet:* Montag, 27. Februar 2023 14:58
> *An:* draft-ietf-alto-new-transp...@ietf.org
> *Cc:* 'alto@ietf.org' 
> *Betreff:* IPR Poll: draft-ietf-alto-new-transport
>
>
>
> Hi Authors,
>
>
>
> Please reply to this email (with the WG mailing list cced) indicating
> whether you are aware of any IPR related to draft-ietf-alto-new-transport.
>
>
>
> If you are aware of any, can you please confirm that all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78 and
> BCP 79 have already been filed?
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Qin & Med
>
>
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>
> Thank you.
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] New transport structural discussion thread

[Y. Richard Yang]

Hi WG, Adrian, Qin, Jordi, all,

Thank you so much for the wonderful reviews of the new alto transport
design. Roland, Lachlan, Kai and I are taking a final pass and will go over
it on Thursday during the interim meeting.

One key issue that we want to discuss, in this specific thread, is a
clarification of the high-level structure:
- Conceptually, the system consists of 3 types of resources:
  (R1) tips, which is a frontend to manage (create/delete) transport states
  (R2) transport state directory, which provides metadata (e.g.,
references) about the network data
  (R3) the actual network data, encoded as alto resources (e.g., cost map,
network map) or incremental updates

One key high-level design decision is the flexibility in locating the 3
types of resources: at one extreme, they are all located on the same
server, and the other extreme (flexible servers) is that they can be
located on separate servers. The advantage of the first "extreme" is that
the first request (R1) can already set up the connection, and hence, there
is a single connection to manage. Hence, it is a simple, clean design. The
advantage of the second "extreme" (flexible servers) is, flexibility, but
the complexity is that it then requires additional connections. In the
current document, it takes a middle ground, R1 can create individual R2 at
different locations, but R2 and its corresponding R3 must be co-located.
Hence, the fetching of R2 opens the connection for R3 as well. One benefit
of this design is that the backend synchronization between R2 and R3 can be
easier.

Another key issue is the relationship between the server state and the
clients' views. In the current design, the specification is that this
relationship is implementation specific, and hence not specified. But it
has become clearer that we need to discuss this issue more to provide
guidance.

The third main issue is whether we allow direct links. From a
structural's point of view, we can consider the view of a client of a
network resource as a directed, acyclic graph, where each node in the graph
is a version of the network resource. Each R3 resource is a link in the
graph. Introducing a virtual root, the client essentially traverses the
links to obtain the resources. An absolute (direct, not incremental)
resource of a version is a direct link from the virtual root directly to
the version, and an incremental resource traverses just one link, from the
previous version to the next version. The current document allows direct
links, but we are discussing the possibility of removing such direct links
by the interim meeting.

Any comments are greatly appreciated and we look forward to a wonderful
meeting soon.

Thank you so much!
Roland, Richard, Lachlan and Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO/TCN presentation at Rucio Community Workshop at the same time w/ ALTO session

[Y. Richard Yang]

Hi all,

It turns out that the ALTO session is at the same time as the Rucio session
when we (Mario/Mihai/Jordi/Harvey/Kai) will present the ALTO/TCN update (
https://indico.cern.ch/event/1185600/timetable/#20221110.detailed). For
those who are not familiar with Rucio/FTS, they are the main data
orchestration and scheduling tools used by CERN and many other major
experiments---FTS moves >1EB data/year (
https://indico.cern.ch/event/1037922/contributions/4528602/attachments/2318396/3947203/FTS_Rucio_Workshop_2021.pdf
).

Hence, some of us may have to switch between the two meetings. We just want
the WG to know.

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

Re: [alto] IETF 115 ALTO Side Meeting

[Y. Richard Yang]

Looks like that webex meeting does not work?

Richard

On Tue, Nov 8, 2022 at 9:11 AM Jordi Ros Giralt 
wrote:

> Let's meet at the Ground floor of the hotel's West Wing. We will find a
> place to talk. (The two only available rooms for side meetings are booked).
>
> For online attendees, let's use our usual webex room:
> https://ietf.webex.com/ietf/j.php?MTID=ma0e97cc97c4cd71bb59cf1a094682686
>
> Qin and Jordi on behalf of ALTO
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF 115 ALTO Side Meeting

[Y. Richard Yang]

Hi Qin, Jordi,

Just to confirm that there will be no regular weekly meeting today at 9 AM
US ET, but a side meeting at 12:30 pm US ET.

Thanks,
Richard


On Sun, Nov 6, 2022 at 11:11 AM Jordi Ros Giralt 
wrote:

> Blocking this time to have an ALTO side meeting during the IETF 115. We
> will soon send the room location for those in London and the
> videoconference link for those remote.
>
> Qin and Jordi on behalf of ALTO
>
>
> 
> Microsoft Teams meeting
> Join on your computer, mobile app or room device
> Click here to join the meeting
> <https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDUyZmNmYWUtNzdmMi00YTRhLTg4M2ItZTQ1NDBkMDNmMTM2%40thread.v2/0?context=%7b%22Tid%22%3a%2298e9ba89-e1a1-4e38-9007-8bdabc25de1d%22%2c%22Oid%22%3a%22b90fe06a-f028-4de4-b117-379d0c4badb5%22%7d>
> Meeting ID: 253 802 794 520
> Passcode: c6dckR
> Download Teams
> <https://www.microsoft.com/en-us/microsoft-teams/download-app> | Join on
> the web <https://www.microsoft.com/microsoft-teams/join-a-meeting>
> Join with a video conferencing device
> 119857...@teams.bjn.vc
> Video Conference ID: 111 815 160 2
> Alternate VTC instructions
> <https://support.bluejeans.com/knowledge/vtc-dial-in-options-for-teams>
> Or call in (audio only)
> +1 858-465-6442,,8589194# <+18584656442,,8589194#>   United States, San
> Diego
> Phone Conference ID: 858 919 4#
> Find a local number
> <https://dialin.teams.microsoft.com/8fe7be77-4808-48e2-bc67-3b5651fa4315?id=8589194>
> | Reset PIN <https://dialin.teams.microsoft.com/usp/pstnconferencing>
> Phones: only use the first Conference ID listed | Video Conferences: only
> use the VTC Conference ID listed
> Learn More <https://aka.ms/JoinTeamsMeeting> | Meeting options
> <https://teams.microsoft.com/meetingOptions/?organizerId=b90fe06a-f028-4de4-b117-379d0c4badb5=98e9ba89-e1a1-4e38-9007-8bdabc25de1d=19_meeting_ZDUyZmNmYWUtNzdmMi00YTRhLTg4M2ItZTQ1NDBkMDNmMTM2@thread.v2=0=en-US>
>
> 
> _______
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF ALTO Hackdemos at 6pm today (Happy Hour)

[Y. Richard Yang]

Echo what Jordi said. There are a lot of ongoing efforts by the ALTO team,
in particular on deployments, led by Jordi and many others. Slightly
earlier, on the same day of the ALTO session (Friday, at Lancaster, U.K.),
we will present the work at Rucio Workshop, on integrating ALTO with Rucio
and FTS. If you are interested in it, please let us know and we can try to
share the link with you.

Very exciting efforts!
Richard

On Mon, Nov 7, 2022 at 11:26 AM Jordi Ros Giralt 
wrote:

> Hi ALTOers:
>
> Just a reminder that today at 6pm (London time) there is the Hackdemo
> Happy Hour, where we will participate by showing the ALTO demos that where
> developed for IETF 115 Hackathon.
>
> In one of the demos led by Qualcomm and the OpenALTO teams, I will be
> showing how we are running ALTO, GradientGraph, PCE and Segment Routing (in
> emulation mode) to steer an XR flow through a 5G edge cloud (
> https://github.com/IETF-Hackathon/ietf115-project-presentations/blob/main/IETF-115-hackathon-ALTO-BSG-XR.pdf
> )
>
> We will also present three new deployments of OpenALTO at CERN/LHCONE,
> GEANT (EU) and the National Research Platform (US), supporting Looking
> Glass, FIB, GradientGraph, and NetFlow, including the openalto.org global
> ALTO query orchestrator. This work is lead by the OpenALTO team (
> https://github.com/IETF-Hackathon/ietf115-project-presentations/blob/main/IETF%20115%20Hackathon%20ALTO%20visibility.pdf
> )
>
> Come by to our table and we look forward to chatting with you.
>
> Jordi
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] openalto.org updates

[Y. Richard Yang]

Hi all,

Sorry to spam the list with one more work-in-progress update email. But
since it is an important, chartered task of the WG, we would like to hear
your feedback and invite more to be involved to work together.

The openalto.org team has two main objectives: (1) design and implement a
high-quality, open-source implementation of ALTO server; and (2) integrate
openalto.org with real application use cases. We plan to provide detailed
updates during the coming IETF'115 ALTO meeting in 3 weeks on Nov. 11 and
this email is to provide a quick overview of progress and thinking. The
openalto implementation and use cases are complementary to the
implementation and use cases by others such as the wonderful project at
Telefonica by Luis.

First, on (1), at the surface, ALTO only defines an interface, and the true
complexity and value of an ALTO server implementation is the process
of obtaining the information resources for an ALTO server to expose. The
current openalto implementation focuses on providing 3 types of
implementations: (A1) from configuration, adjacency, and other input such
as BGP inputs, (A2) from reading FIB directly, and (A3) from available
sampling FIB (e.g., s-flow/netflow report, traceroute essentially sampling
by ttl and ICMP report). So far good process has been made for A2 (for
looking glass for CERN and others) and A3 (based on s-flow, and others, on
top of G2 led by Jordi and Sruthi). There are also efforts to make progress
on A1, using batfish and there is ongoing work to apply the approach to
ESnet.

Building on the progress of having many ALTO servers running, the openalto
team includes a new effort to organize the existing ALTO servers. Although
there are existing ALTO server discovery mechanisms, openalto.org will now
serve as a frontend to many servers which will become available soon. One
major departure of this approach from the original ALTO thinking is that
openalto allows multiple ALTO servers to serve a single network. Hence,
openalto.org is organized as a structure motivated by the DNS structure, as
..openalto.org. For example, as513.lg.openalto.org is the
ALTO server for entity AS513 (CERN) implemented by A3 (Looking Glass
server) domain. Hence, the deployment structure is an overlay structure,
with base servers that can be overridden by authoritative servers. We feel
that this is a great way to go.

In addition to serving as a hub of network composition, the current
openalto.org will also serve as a frontend to provide a unified query
interface to existing networking information. An example that will be
deployed is to make ALTO a frontend to geoip data, in the domain of
geoip.openalto.org.

For (2), the current focus of openalto is for two applications: the
application-layer scheduling integration into FTS, which is the main
scheduling system at LHC and many others; and Rucio, which is the transfer
selection/data orchestration framework. For FTS, openalto provides the
important assets that a transfer utilizes and then the scheduler, which
knows the app and the amount of data transferred, can conduct
application-level resource partition among multiple application-level
entities (experiments/projects/activities). For Rucio, openalto provides
distance (cost map) as a unifying abstraction, including FTS distance, to
guide the transfer selection. These use cases are different from other use
cases such as those described by Luis.

We welcome feedback and broad participation. Please let us know if you can
help.

Thanks,

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

Re: [alto] I-D Action: draft-ietf-alto-new-transport-02.txt

[Y. Richard Yang]

Hi all,

We have posted a newer version of transport, which includes part of the
spec. As a recap of previous discussions, the complete spec will include
four components: (1) version independent structures; (2) client (long)
poll; (3) server push to client, and (4) server (as http client) put to
client (as http server). The version just posted include (1) and (2). We
will post (3) soon, and Lauren will work with us. As we discussed, (4) will
be left as an option, but not now.

Any quick feedback/comments are highly welcome!

Richard on behalf of authors

On Thu, Oct 20, 2022 at 11:32 PM  wrote:

>
> 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   : ALTO New Transport: ALTO Transport Information
> Structures
> Authors : Roland Schott
>       Y. Richard Yang
>   Kai Gao
>   Jingxuan Jensen Zhang
>   Filename: draft-ietf-alto-new-transport-02.txt
>   Pages   : 22
>   Date: 2022-10-20
>
> Abstract:
>The ALTO base protocol [RFC7285] defines both the ALTO information
>resources and their transport from the server to the client.  Using
>HTTP/1.x as the transport protocol, the ALTO transport in the base
>protocol includes the limitations of HTTP/1.x.  ALTO/SSE [RFC8895]
>defines a new transport design addressing some of the limitations,
>but is still based on HTTP/1.x.  This document introduces ALTO new
>transport, which introduces ALTO transport information structures
>(TIS) at an ALTO server.  The introduction of ALTO TIS allows at
>least two types of efficient transport using HTTP: (1) HTTP/2/3
>independent client (long) poll allowed by non-blocking, newer HTTP,
>and (2) HTTP/2 specific server push.  This document defines ALTO TIS
>and the first design.  A companion document defines server-push ALTO
>transport based on ALTO TIS.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-alto-new-transport-02.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-new-transport-02
>
>
> 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
>
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] LHCONE deep visibility deployment using ALTO

[Y. Richard Yang]

Hi WG,

Sorry for the spam. Deployment is another topic which we will discuss in
the coming weekly meeting. Below is a quick email update to save update
time so that we can focus on discussions at the meeting.

There were 3 meetings yesterday to push the effort forward: an early
meeting with Edoardo Martelli (CERN), the next GNA-G meeting and then the
short meeting with Tom Lehman (ESnet). These are wonderful, collaborative
meetings. The goal is to push forward the base component: a deep visible
ability into the LHCONE network, which is the largest network supporting
multiple workloads.

So far, the implementations push on two approaches: A1 extracting the
routing information base (RIB) directly (currently based on NAPALM), and A2
extracting control plane configuration and computing the RIB (currently
based on batfish)

There are two main challenges: (1) wide deployment with partial visibility
(not able to get access to all routers), and (2) visibility into “physical”
assets, not higher level L3 links.

During the weekly meeting, we will discuss the details. In the 4 pm ET
meeting today, we will continue to work with Dr. Tom Lehman and Chin Guok.
All are welcome to work together to push forward the deployment.

Thanks,

Richard

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

[alto] Http/2/3 version independent transport finalization

[Y. Richard Yang]

Hi WG,

Updating transport mechanisms is an WG item and we are getting close to the
milestone (in September). Hence, the authors are finalizing the updates as
soon they can, and the topic will be a main item for the coming weekly
meeting. It was suggested that we send out some main points for others to
think about them before the meeting.

In particular, the goal is to finalize the version-dependent design, where
by version independent, it means that the design can benefit from
improvements in http without explicit control. Applying the inference, it
means that the design should not use version specific methods, which will
be PUSH_PROMISE. In other words, it should use only base http/1.x methods;
that is, we use GET/PUT/POST.

In this design space, there are still two design points: (D1): introducing
PUT; (2) not introducing PUT.

For discussion, we need to distinguish between ALTO server/client and HTTP
server/client. In general design, an ALTO server can be an HTTP client and
so on.

For D1, to allow ALTO server pushing updates using PUT, the ALTO server
needs to become an HTTP client. Hence, it needs two HTTP connections, with
in one the ALTO server being an HTTP client and the other HTTP server.

For D2, it needs only one HTTP connection, and the efficiency depends on
low long-poll overhead in non-blocking HTTP/2/3.

The authors prefer D2 and will finalize the document in a couple days. Any
comments are greatly appreciated.

Richard, Roland, Kai and Jensen
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] RFC 9275 on An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector

[Y. Richard Yang]

Hi Qin, all,

This is a good progress indeed. I share with you that many WG members
including both the authors and many others have made contributions in the
process. A big thank you!

Richard

On Fri, Sep 23, 2022 at 9:13 PM Qin Wu 
wrote:

> Congratulation to all authors and other people who contributed to this
> work all the way along!
>
> -Qin (on behalf of chairs)
> -邮件原件-
> 发件人: alto [mailto:alto-boun...@ietf.org] 代表 rfc-edi...@rfc-editor.org
> 发送时间: 2022年9月24日 4:39
> 收件人: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
> 抄送: rfc-edi...@rfc-editor.org; drafts-update-...@iana.org; alto@ietf.org
> 主题: [alto] RFC 9275 on An Extension for Application-Layer Traffic
> Optimization (ALTO): Path Vector
>
> A new Request for Comments is now available in online RFC libraries.
>
>
> RFC 9275
>
> Title:  An Extension for Application-Layer Traffic
> Optimization (ALTO): Path Vector
> Author: K. Gao,
> Y. Lee,
> S. Randriamasy,
> Y. Yang,
> J. Zhang
> Status: Experimental
> Stream: IETF
> Date:   September 2022
> Mailbox:kai...@scu.edu.cn,
> younglee...@gmail.com,
> sabine.randriam...@nokia-bell-labs.com,
> y...@cs.yale.edu,
> jingxuan.n.zh...@gmail.com
> Pages:  54
> Updates/Obsoletes/SeeAlso:   None
>
> I-D Tag:draft-ietf-alto-path-vector-25.txt
>
> URL:https://www.rfc-editor.org/info/rfc9275
>
> DOI:10.17487/RFC9275
>
> 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 to which
> endpoint(s) to connect based not only on numerical/ordinal cost values but
> also on fine-grained abstract information regarding the paths. This is
> useful for applications whose performance is impacted by specific
> 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 the
> "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.
>
> This document is a product of the Application-Layer Traffic Optimization
> Working Group of the IETF.
>
>
> EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet
> community.  It does not specify an Internet standard of any kind.
> Discussion and suggestions for improvement are requested.
> Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search For
> downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the author
> of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for unlimited
> distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO service query spanning multiple domains (ECS)

[Y. Richard Yang]

Hi all,

There were quite extensive discussions, on the reactive/on-demand,
multi-domain design below, during the weekly meeting early this morning and
here is a brief summary of the key points.

- The design can be decomposed into two components: routing composition and
cost metric composition, from single domains to multiple domains:
   (metricVal, egressIP) = alto-server.query(ingressIP, srcIP, dstIP,
metric)
   =>
   egressIP = query(ingressIP, pkt-attributes)  // Q1
   metricVal = query(ingressIP, pkt-attributes, metric) //Q2

- It turns out that there can be at least multiple potential design points:
  For Q1: It can have two designs:
 - D1.1 It can be that Q1 is out of scope for ALTO, for example, by
using a routing system to conduct the query
 - D1.2 It can be a new service/metric type in ALTO

  For Q2: it also can have two designs:
 - D2.1 using the current RFC7285 for Q2, with specifying ingressIP as
src, in the ECS query
   This design is good if a network is destination-based routing
 - D2.2 We add an extension to ALTO ECS, to include general packet (and
pseudo packet) attributes

  For the extension design path, it can help to
  (1) convey the matching requirements in the IRD (for example, what
packet attributes to be included)
  (2) return indicates the equivalent classes (matching masks).

The design team will proceed with the simple designs first to push forward
the deployment, but will document the proceeding.

Cheers,
Richard



On Mon, Sep 12, 2022 at 10:50 PM Y. Richard Yang  wrote:

> Hi all,
>
> During the weekly meeting last week, we went over the details when
> deploying ALTO in a multi-domain setting, say the FTS/Rucio setting
> supporting the TCN deployment [1]. Below is the endpoint cost service (ECS)
> case, and it was suggested that we post it to the WG mailing list to update
> the WG and get potential feedback.
>
> Problem: An ALTO client queries the endpoint cost from srcIP to dstIP for
> a given performance metric (e.g., latency). Consider the case that the
> srcIP and dstIP belong to different networks, with the whole layer-3 path
> as the list [ip[0], ip[1], ..., ip[N]], where ip[0] = srcIP and ip[N] =
> dstIP. Define Net(ip) as the function that maps an IP address to the
> network that owns the IP---ignore the complexity such as anycast since the
> deployment does not have this case. Then Net(srcIP) != Net(dstIP), if it is
> multi-domain. Consider the initial deployment that we have only an ALTO
> server for each network; that is, it provides ALTO service for only
> Net(srcIP) == Net(dstIP). Then, there is not a single ALTO server that can
> provide the answer.
>
> Basic solution (one src-dst flow): Map the list [ip[0], ..., ip[N]] to a
> list of segments, where each segment starts with an IP address, and ends
> with the first IP address in the sequence that leaves the network of the
> start IP address. Hence, the basic query framework at an aggreation ALTO
> client:
> - alto-ecs(srcIP, dstIP, metric)
>   metrics = EMPTY
>   ingressIP = srcIP
>   do {
>   alto-server = server-discovery(ingressIP)
>   (metricVal, egressIP) = alto-server.query(ingressIP, srcIP, dstIP,
> metric)
>   metrics.add(metricVal)
>   ingressIP = egressIP
>   } while (egressIP != dstIP)
>
> The preceding assumes a procedure that collects segment attributes, and it
> can be a single pass composition using a metric-dependent function (e.g.,
> latency is addition, and bw is min).
>
> Multi-flow queries: ALTO ECS supports the querying of multiple src-dst
> pairs. A simple solution is to query each src-dst pair one-by-one. Such a
> query is necessary because the routing can be dependent on packet
> attributes (srcIP, dstIP) and a pseudo packet attribute (ingressIP), and
> the ALTO client cannot reuse the results. To allow reuse (both in
> multi-flow queries and caching of past queries), it helps that the ALTO
> server indicates equivalent classes, which Kai and Jensen investigated.
>
> A revision of the protocol using caching and equivalent class is:
> alto-server-cache: indexed by ALTO server,  pairs
> - alto-ecs(srcIP, dstIP, metric)
>   metrics = EMPTY
>   ingressIP = srcIP
>   do {
>   alto-server = server-discovery(ingressIP)
>   if (alto-server-cache.match(alto-server, ingressIP, srcIP, dstIP)
>  use cache results
>   else
>  (metricVal, egressIP; ingressIPMask, srcIPMask, dstIPMask)
>  = alto-server.query(ingressIP, srcIP, dstIP, metric)
>  alto-server-cache.add(alto-server, ,
> , 
>   metrics.add(metricVal)
>   ingressIP = egressIP
>   } while (egressIP != dstIP)
>
> The mask design is a special case. For the general case, the most flexible
> equivalent class 

[alto] open alto development update

[Y. Richard Yang]

Hi all,

Sorry to spam the mailing list with a second email message.

During the weekly meeting last week, we also discussed about the progress
and planning for the testing and deployment of TCN, which uses alto and is
based on our past progress. It was suggested that we post the planning (in
reverse chronological order) to engage the WG broadly.

- IETF 115 hackathon (11/2022): The main target is the partial deployment
(a parallel controller domain) that integrates alto into FTS to realize the
resource control

- LHCOPN/LHCONE meeting (10/25/2022): This will serve as a checkpoint, to
seek feedback from the broad CERN community to refine the current design

- GRP meeting (10/12/2022): This is the checkpoint to realize the first
running CERN infrastructure.

We will be happy to provide more details and feel free to get in touch.

Richard, Jordi on behalf of the team

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

[alto] ALTO service query spanning multiple domains (ECS)

[Y. Richard Yang]

Hi all,

During the weekly meeting last week, we went over the details when
deploying ALTO in a multi-domain setting, say the FTS/Rucio setting
supporting the TCN deployment [1]. Below is the endpoint cost service (ECS)
case, and it was suggested that we post it to the WG mailing list to update
the WG and get potential feedback.

Problem: An ALTO client queries the endpoint cost from srcIP to dstIP for a
given performance metric (e.g., latency). Consider the case that the srcIP
and dstIP belong to different networks, with the whole layer-3 path as the
list [ip[0], ip[1], ..., ip[N]], where ip[0] = srcIP and ip[N] = dstIP.
Define Net(ip) as the function that maps an IP address to the network that
owns the IP---ignore the complexity such as anycast since the deployment
does not have this case. Then Net(srcIP) != Net(dstIP), if it is
multi-domain. Consider the initial deployment that we have only an ALTO
server for each network; that is, it provides ALTO service for only
Net(srcIP) == Net(dstIP). Then, there is not a single ALTO server that can
provide the answer.

Basic solution (one src-dst flow): Map the list [ip[0], ..., ip[N]] to a
list of segments, where each segment starts with an IP address, and ends
with the first IP address in the sequence that leaves the network of the
start IP address. Hence, the basic query framework at an aggreation ALTO
client:
- alto-ecs(srcIP, dstIP, metric)
  metrics = EMPTY
  ingressIP = srcIP
  do {
  alto-server = server-discovery(ingressIP)
  (metricVal, egressIP) = alto-server.query(ingressIP, srcIP, dstIP,
metric)
  metrics.add(metricVal)
  ingressIP = egressIP
  } while (egressIP != dstIP)

The preceding assumes a procedure that collects segment attributes, and it
can be a single pass composition using a metric-dependent function (e.g.,
latency is addition, and bw is min).

Multi-flow queries: ALTO ECS supports the querying of multiple src-dst
pairs. A simple solution is to query each src-dst pair one-by-one. Such a
query is necessary because the routing can be dependent on packet
attributes (srcIP, dstIP) and a pseudo packet attribute (ingressIP), and
the ALTO client cannot reuse the results. To allow reuse (both in
multi-flow queries and caching of past queries), it helps that the ALTO
server indicates equivalent classes, which Kai and Jensen investigated.

A revision of the protocol using caching and equivalent class is:
alto-server-cache: indexed by ALTO server,  pairs
- alto-ecs(srcIP, dstIP, metric)
  metrics = EMPTY
  ingressIP = srcIP
  do {
  alto-server = server-discovery(ingressIP)
  if (alto-server-cache.match(alto-server, ingressIP, srcIP, dstIP)
 use cache results
  else
 (metricVal, egressIP; ingressIPMask, srcIPMask, dstIPMask)
 = alto-server.query(ingressIP, srcIP, dstIP, metric)
 alto-server-cache.add(alto-server, ,
, 
  metrics.add(metricVal)
  ingressIP = egressIP
  } while (egressIP != dstIP)

The mask design is a special case. For the general case, the most flexible
equivalent class may be using predicates (e.g., supporting identifying the
lower entries of longest prefix matching). It is an issue that can benefit
from more benchmarking, or if there are any related pointers, the team will
appreciate the pointers.

In the next email, Kai and Jensen will post a slightly different design
supporting a map oriented service.

Cheers,

[1] Transport control networking: optimizing efficiency and control of data
transport for data-intensive networks,
https://dl.acm.org/doi/abs/10.1145/3538401.3548550
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Skip ALTO weekly meeting this week (Aug. 23); SIGCOMM NAI on Monday (Aug. 22)

[Y. Richard Yang]

Hi all,

Since many of us are away this week, may I suggest that we cancel the WG
weekly meeting this Tuesday (Aug. 23)?

As a small advertisement for Luis, the SIGCOMM network-application
integration (NAI'22) workshop chaired by Lui is tomorrow (Aug. 22, 2022).
It has an extremely interesting program consisting of keynote presentations
and papers. You can check the program here:
https://conferences.sigcomm.org/sigcomm/2022/workshop-nai.html
If you need access to the zoom link as a remote participant, please send me
a note (y...@cs.yale.edu or yang.r.y...@gmail.com).

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

Re: [alto] Presenting ALTO-related work at MOPS WG on Friday

[Y. Richard Yang]

I was at the presentations by Luis. Excellent presentation and great Q!
We should share the questions and answers back to this mailing list.

Richard

On Fri, Jul 29, 2022 at 11:52 AM  wrote:

> Hi all,
>
>
>
> The slides that are presented by Luis can be seen at:
> https://datatracker.ietf.org/meeting/114/materials/slides-114-mops-exposure-of-telefonica-network-topology-through-alto-for-integration-with-telefonica-cdn/
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* alto  *De la part de* LUIS MIGUEL CONTRERAS
> MURILLO
> *Envoyé :* lundi 25 juillet 2022 23:32
> *À :* 'alto@ietf.org' 
> *Objet :* [alto] Presenting ALTO-related work at MOPS WG on Friday
>
>
>
> Dear ALTOers,
>
>
>
> For those interested, next Friday at MOPS WG I will have the opportunity
> to present the work in Telefonica for the integration of ALTO as a way of
> exposing topology information to Telefonica CDN.
>
>
>
> The session is entitled “Exposure of Telefonica network topology through
> ALTO for integration with Telefonica CDN” (
> https://datatracker.ietf.org/meeting/114/materials/agenda-114-mops-02.txt
> ).
>
>
>
> Best regards
>
>
>
> Luis
>
>
>
> __
>
> Luis M. Contreras
>
>
>
> Transport & IP Networks
>
> Systems and Network Global Direction
>
> Telefónica I+D / CTIO unit / Telefónica
>
>
>
> Distrito Telefónica, Edificio Sur 3, Planta 3
>
> 28050 Madrid
>
> España / Spain
>
>
>
> Mobile: +34 680 947 650
>
> luismiguel.contrerasmuri...@telefonica.com
>
>
>
>
> --
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Dinner IETF ALTO team - IETF 114 Philadelphia

[Y. Richard Yang]

Thanks for the update, Jordi. So we just meet at Maggiano's Little Italy at
7:30.

For some of you who want to stop by to see the hackathon demo, Mahdi and
some others will be at the Hackathon Happy Hour from 5:30-6:30 pm. Feel
free to stop by as well.

Richard

On Mon, Jul 25, 2022 at 4:39 AM alto  wrote:

> Confirming that we reservations for the restaurant Maggiano's Little
> Italy. In order to accommodate all of us, I could only find a table at
> 7:30pm, hope that time works for all of you who accepted.
>
> Here are the coordinates:
>
> *When: Mon july 25, at 7:30pm EST*
> *Where: Maggiano's Little Italy. It's a 14' walk from the Sheraton.
> Directions: https://goo.gl/maps/n14tiEGEYvCZdsJfA
> *
>
> If anybody else wants to attend who still has not confirmed, we should
> still have a bit of room to have you.
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF 114 ALTO Hackathon projects

[Y. Richard Yang]

Hi Mihai, Steve, Mario, all,

This is an update on the IETF hackathon which just finished today (July 24)
in Philadelphia, PA. Mahdi presented the results to the whole hackathon
audience at slightly over 2 pm on behalf of the team. The initial
integration of ALTO and FTS and the zero-order algorithm are fully
functional (at least in the concurrent setting).

This excellent progress is the result of hard work that takes a village;
Jensen stayed up 24 hours non-stop until 2 pm to finish up the FTS
production code integration framework, Mahdi was sleeping only 4 hours per
day in consecutive days to implement the full zero-order gradient
algorithm, Kai and his team made great progress on implementing openalto
with both standard features (path vector) and next step features (FCS), and
the team worked under the great organization of Jordi. We plan to do some
more demos and socials tomorrow (Monday) at the IETF Happy Hour to try to
get more IETF feedback. The working slides are at:
https://docs.google.com/presentation/d/1CcCMvZ_SeWLRAN32Qz8RFcHrF8spAu_6/edit?usp=sharing=110882839032059047983=true=true

As soon as the IETF this week is over, we will schedule an overall group
meeting to go over the technical details, and plan for the next steps. I
consider HTTP a great example of a hugely successful collaboration between
the networking community (IETF) and the data sciences (CERN). Let's use
this project to promote collaboration between these two communities again.

Cheers,

Richard for the team



On Thu, Jul 21, 2022 at 4:08 AM Mihai Patrascoiu 
wrote:

> Hello Richard,
>
> I'll summarize my answers from the other thread.
>
> Unfortunately, due to other arrangements, we won't be able to attend the
> hackathon this weekend.
>
> However, we are very excited about the proposed objectives. We already
> established a way for the FTS Optimizer zero-order algorithm to make it's
> way into production. Once the feature is ready, with the help of Mario, we
> can organize a large-scale test and compare the results we get in
> production with the simulated results.
>
> On further ALTO and FTS integration, one aspect I see particularly
> promising is:
> 1. Use ALTO information to assess the network capability of a given RSE
> 2. Set a maximum limit for how much network percentage FTS can occupy. In
> a feedback loop via ALTO, FTS would find whether it may increase or should
> decrease traffic involving that RSE
>
> This maps directly to what we see in production: FTS can hit some sites
> too hard.
> Any extra knowledge FTS gets on this aspect would allow it to improve.
>
> Best Regards,
> Mihai for the FTS team
>
> On 20/07/2022 03:58 Y. Richard Yang  wrote:
>
>
> Hi all,
>
> During the weekly ALTO meeting today, we discussed the coming hackathon
> and Qin suggested that we send an update to the mailing list on the
> FTS+ALTO project, and here is the update:
>
> - In short, if you want to work on ALTO integration with production, open
> projects, this can be a wonderful project to work on: it may help both ALTO
> (in terms of its crucial deployment mandate) and the largest data-intensive
> science projects at CERN.
>
> Specifically:
> - For those who have not tracked the hackathon, as Jordi said, it is a
> continuation of the 113 Hackathon.  In particular, the 113 Hackathon
> focused on the integration with Rucio, which is a wonderfully designed tool
> used widely in CERN and some other projects for data movement of a large
> amount of data (PB -> EB). In 113, the hackathon modified the manual
> workflow, which is the workflow to select the source to download a dataset
> when a client issues a download command. The other workflow of Rucio is the
> automatic workflow, which selects the sources and destinations to realize
> user-specified replication rules. In our original plan, 114 would focus on
> the automatic workflow. However, the team realized that Rucio is built on
> top of FTS, which is the main tool used at CERN to schedule which transfer
> is scheduled at what time, where Rucio is at a higher layer providing the
> transfers for FTS to schedule.
>
> - The 114 hackathon includes 2 objectives: (1) introducing resource
> control to FTS, and (2) evaluating an alternative design of FTS core: the
> FTS Optimizer. Hence, the work includes 3 components, integrating the FTS
> production code and framework:
> (1/basic) allow FTS to specify resource control goal and use ALTO to map
> FTS control state (called links in FTS, where a link is a pair consisting
> of a source node to a destination node, where a node is called RSE) to
> network state;
> (2/basic) implement a full zero-order algorithm, to achieve fully
> efficient, zero-order gradient control as FTS Optimizer;
> (3/stretch) realize a composition framework to com

Re: [alto] alto transport streams (Re: early reviews)

[Y. Richard Yang]

Hi Spencer,

Thank you so much for the reviews from both you and Mark. We are working on
how to address the additional comments from you including the configuration
settings issues. We are discussing them and will respond soon.

Thanks again!
Richard

On Fri, Jul 22, 2022 at 12:27 PM Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:

> I'd just like to note that I kept asking myself what Mark Nottingham would
> say, while thinking about my own review comments - I'm really glad to see
> that you're also talking to Mark!
>
> Best,
>
> Spencer
>
> On Thu, Jul 21, 2022, 23:00 Mark Nottingham  wrote:
>
>> Hi Richard,
>>
>> I'm just going to give some impressions while reading this, FWIW.
>>
>> > On 22 Jul 2022, at 6:20 am, Y. Richard Yang  wrote:
>> >
>> > Hi Mark, Martin, Spencer,
>> >
>> > First, thank you so much for the reviews. Sorry for the delay in
>> responding asap, due to summer and travel.
>> >
>> > One common comment we see from all three of you, in different texts, is
>> essentially on the service model of the current document (
>> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/): how
>> much control on the ordering of the messages (Mark/Martin), in-order or not
>> (Spencer). Hence, after the meeting early morning today, we feel that we
>> should start a single thread to discuss this issue. We will send a summary
>> of our responses to each of your individual reviews later.
>> >
>> > To help make clear the problem and the current design, let's start by
>> summarizing the transport model of ALTO/SSE (RFC8895;
>> https://datatracker.ietf.org/doc/html/rfc8895). We will state the
>> problem as abstract as possible to see the essence of the problem and the
>> potential design choices:
>> > - P1: A server offers multiple resources R = {R[1], R[2], R[3], R[4],
>> ...}, where each R[i]i is represnted by a URI;
>>
>> Good so far; that's pretty much a description of every use of HTTP.
>>
>> > - P2: A client can request from the server the monitoring of a subset M
>> of the resources: M \subset R, e.g., M = {R[1], R[2], R[3]}; for example,
>> R[1] is a network map, R[2] is a cost map using the network map R[1], and
>> R[3] is an endpoint property map; for simplicity, assume the requested
>> resources numbered 1 to |M|
>>
>> So, in HTTP terms, that would be creating a new resource whose semantic
>> is "I am a monitor for  _this_ set of resources". The tricky party here is
>> how to realise that in terms of HTTP -- i.e., what does a GET response look
>> like?
>>
>> One answer would be a feed format like RSS or Atom. Do you support GET in
>> this fashion?
>>
>> > - P3: The server can push a sequence of incremental updates to the
>> client for each resource in M. Denote {U[i,1], U[i,2], ...} as the update
>> sequence from the server to the client for R[i] in M, where U[i,1] is the
>> first response for the requested resource R[i], U[i,2] is an incremental
>> update (patch) on top of U[i,1], U[i,3] is the incremental update on top of
>> U[i,2], ...
>>
>> Here's where I get more concerned. Server Push is unproven, and indeed
>> has been shown to be an anti-pattern for its originally intended use case.
>> Folks are still interested in it for API use cases (and I'd see this as one
>> of those), but it's still very wild west, with no real widespread
>> deployment experience that I'm aware of. See especially <
>> https://httpwg.org/specs/rfc9205.html#server-push>.
>>
>> The first question I'd ask here is whether polling a resource (like a
>> feed document) is sufficient. That pattern works very well with HTTP, and
>> is well-understood -- _much_ more so than Server Push.
>>
>> The downside, of course, is latency, but it's not unknown to deploy
>> applications with very high polling frequencies (e.g., 1/s). Have you
>> considered this approach? Would modifying it to long-polling (where the
>> client always keeps a request 'hanging' until the server has an update)
>> help? Keep in mind that with HTTP/2 and above, long-polling has very few
>> downsides.
>>
>> Another option would be to invert the relationship and have what's
>> currently the server open connections to the current client and PUT / PATCH
>> updates to them. Much more natural HTTP, but of course you need an identity
>> for the client and a clear path to it. This approach also has considerable
>> deployment experience (commonly known as 'webhooks').
>>
>> > - P3.1: For flexibility, each U[i,

Re: [alto] alto transport streams (Re: early reviews)

[Y. Richard Yang]

Hi Mark,

Thank you so much for the quick feedback. Sorry for the delay as we were
traveling ...

Please see below.

On Thu, Jul 21, 2022 at 11:00 PM Mark Nottingham  wrote:

> Hi Richard,
>
> I'm just going to give some impressions while reading this, FWIW.
>
> > On 22 Jul 2022, at 6:20 am, Y. Richard Yang  wrote:
> >
> > Hi Mark, Martin, Spencer,
> >
> > First, thank you so much for the reviews. Sorry for the delay in
> responding asap, due to summer and travel.
> >
> > One common comment we see from all three of you, in different texts, is
> essentially on the service model of the current document (
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/): how
> much control on the ordering of the messages (Mark/Martin), in-order or not
> (Spencer). Hence, after the meeting early morning today, we feel that we
> should start a single thread to discuss this issue. We will send a summary
> of our responses to each of your individual reviews later.
> >
> > To help make clear the problem and the current design, let's start by
> summarizing the transport model of ALTO/SSE (RFC8895;
> https://datatracker.ietf.org/doc/html/rfc8895). We will state the problem
> as abstract as possible to see the essence of the problem and the potential
> design choices:
> > - P1: A server offers multiple resources R = {R[1], R[2], R[3], R[4],
> ...}, where each R[i]i is represnted by a URI;
>
> Good so far; that's pretty much a description of every use of HTTP.
>
> > - P2: A client can request from the server the monitoring of a subset M
> of the resources: M \subset R, e.g., M = {R[1], R[2], R[3]}; for example,
> R[1] is a network map, R[2] is a cost map using the network map R[1], and
> R[3] is an endpoint property map; for simplicity, assume the requested
> resources numbered 1 to |M|
>
> So, in HTTP terms, that would be creating a new resource whose semantic is
> "I am a monitor for  _this_ set of resources". The tricky party here is how
> to realise that in terms of HTTP -- i.e., what does a GET response look
> like?
>
> One answer would be a feed format like RSS or Atom. Do you support GET in
> this fashion?
>

A new resource whose semantic is "I am a monitor for  _this_ set of
resources" is a good term to use. In the current design, we refer to it as
the transport queue: the request (using POST, to provide parameters)
returns a URI to the (transport queue) resource. Make sense?

> - P3: The server can push a sequence of incremental updates to the client
> for each resource in M. Denote {U[i,1], U[i,2], ...} as the update sequence
> from the server to the client for R[i] in M, where U[i,1] is the first
> response for the requested resource R[i], U[i,2] is an incremental update
> (patch) on top of U[i,1], U[i,3] is the incremental update on top of
> U[i,2], ...
>
> Here's where I get more concerned. Server Push is unproven, and indeed has
> been shown to be an anti-pattern for its originally intended use case.
> Folks are still interested in it for API use cases (and I'd see this as one
> of those), but it's still very wild west, with no real widespread
> deployment experience that I'm aware of. See especially <
> https://httpwg.org/specs/rfc9205.html#server-push>.
>
> The first question I'd ask here is whether polling a resource (like a feed
> document) is sufficient. That pattern works very well with HTTP, and is
> well-understood -- _much_ more so than Server Push.
>
> The downside, of course, is latency, but it's not unknown to deploy
> applications with very high polling frequencies (e.g., 1/s). Have you
> considered this approach? Would modifying it to long-polling (where the
> client always keeps a request 'hanging' until the server has an update)
> help? Keep in mind that with HTTP/2 and above, long-polling has very few
> downsides.
>

This is an excellent comment! We looked at the current design, and see that
integrating long poll is quite clean, easy-to-add. In particular, the
current design is to provide an incremental update queue, which provides
the seq numbers; an example of the updates queue is the following:
{
  [
{“seq”:101,
 "media-type": "application/alto-costmap+json",
 “tag”:"a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" },
{“seq”:102,
 "media-type": "application/merge-patch+json",
 “tag”:"cdf0222x59740b0b2e3f8eb1d4785acd42231bfe" },
{“seq”:103,
 "media-type": "application/merge-patch+json",
 “tag”:"8eb1d4785acd42231bfecdf0222x59740b0b2e3f",
 "link":   "

Re: [alto] HTTP Review (draft-ietf-alto-new-transport)

[Y. Richard Yang]

Hi Mark,

Thank you so much for the feedback. Could you please see
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/
for an attempt to formulate a generic problem.

As soon as we have a discussion on the generic issue, we will update the
document accordingly, for example, to decide to use HTTP/1.x textual
representation---we used HTTP/1.1 textual and then found that the example
need to illustrate details such as the promised stream (see Promised Stream
4 as an example). We will update as soon as we have a discussion on the
generic thread.

Thanks again!
Richard


On Sun, Jul 17, 2022 at 4:05 AM Mark Nottingham  wrote:

> I've taken a look at this document.
>
> My high-level feedback is that in principle it's reasonable use of HTTP,
> but how it talks about HTTP versioning and a few other details isn't
> appropriate. I think that a few small editorial updates could improve
> things, and would be happy to make a pull request if you happen to be using
> a Github-based process.
>
> What raises concerns for me is referring to this as 'ALTO/h2' and similar
> things. If you're designing an application that uses HTTP, you need to
> acknowledge that you can't always control the end-to-end version of the
> protocol used, and while you can optimise for newer versions of the
> protocol, you have to be prepared for downgrading to previous ones.
>
> That means that this isn't really "ALTO/h2", it's a new version of ALTO
> that operates more smoothly under later versions of the protocol.
>
> DoH threaded this particular needle as well; rather than branding it as
> "DNS/h2", they merely said " HTTP/2 [RFC7540] is the minimum RECOMMENDED
> version of HTTP for use with DoH." and then: "Earlier versions of HTTP are
> capable of conveying the semantic requirements of DoH but may result in
> very poor performance."
>
> In this spirit, I'd recommend avoiding using the HTTP/2 textual
> representation for examples; most developers are much more familiar with
> HTTP/1.1 when consuming examples, and HTTP/2 contains details which aren't
> relevant for the purpose of conveying an example (we've settled on this
> approach in the HTTP editorial style, see <
> https://httpwg.org/admin/editors/style-guide>).
>
> Note that I haven't done a full review; these are just the things I saw
> after a quick look.
>
> Cheers,
>
>
>
> > On 11 Jul 2022, at 1:37 pm, Mark Nottingham  wrote:
> >
> > Hi folks,
> >
> > I've been asked to forward this request for early review; does anyone
> want to take a look?
> >
> > Feedback to alto@ietf.org.
> >
> > Cheers,
> >
> >
> >> Begin forwarded message:
> >>
> >> From: 
> >> Subject: HTTP Review (draft-ietf-alto-new-transport)
> >> Date: 6 July 2022 at 12:56:56 am AEST
> >> To: Mark Nottingham 
> >> Cc: Qin Wu , "
> draft-ietf-alto-new-transp...@ietf.org" <
> draft-ietf-alto-new-transp...@ietf.org>
> >>
> >> The ALTO WG is currently working on the specification available at:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/. The
> current version focuses on H2 with the intent to cover at least common
> H2/H3 functionalities.
> >>
> >> The WG is seeking for early reviews so that issues/advice are taken
> into account early in the process.
> >>
> >> We are particularly interested in comments about the handling of H3,
> especially with regards to the guidelines in RFC9250 about HTTP versioning.
> >>
> >> Of course, comments related to other considerations in the draft are
> more than welcome.
> >>
> >> Thank you.
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Fwd: HTTP Review (draft-ietf-alto-new-transport)

[Y. Richard Yang]

Hi Martin,

Sorry that I did not include you in the previous email--auto completion of
email address included a different Martin :-( My apologies.  Please kindly
see this message:
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/

Please see below for more comments.

On Mon, Jul 11, 2022 at 1:28 AM Martin Thomson  wrote:

> ALTO is very much a protocol that is defined in terms of core HTTP
> semantics (see RFC 9205, Section 4.1).  It refers to RFC 7230 (the
> then-current version) rather than RFC 7231 as perhaps it should have, but I
> couldn't see any place where the use of HTTP semantics were
> version-specific.
>
> That makes this document a little surprising.  Most protocols that use
> HTTP benefit from HTTP/2 and HTTP/3 by doing exactly nothing in
> specifications.  You just update software.  This document is a fair bit
> more than nothing.
>
>
Please see the generic discussion in the previous email (
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/) on
why the current version specified the additional details.

To summarize shortly, the problem is that
(1) a server needs to push a set of resources Ui to a client, there can be
dependencies among the Ui, and how to map each Ui to which stream (in
HTTP/2 or HTTP/3);
(2) each Ui already has a media type, and if multiple Ui are mapped to the
same stream, how to indicate so in the push header and what is the
container media type.

The decision in the current document is:
- Map each Ui to an independent stream (so that no container issue for (2)
-  Instruct the server to respect the dependency to optimize the
transmissions (e.g., by transmitting Ui before Uj, if Uj depends on Ui).


> The new concept of transport queues is added, but I couldn't work out what
> they do.  Maybe there is something related to server push.  I found this
> part to be poorly rationalized and the explanation concentrates on
> mechanisms to the detriment of explaining what the functions provided are
> intended to do.  I can guess based on RFC 8895 what they might do, but I
> think that this document should probably do some more explaining about that.
>
>
Good suggestion. We can add some text to explain, and here is the
high-level reasoning motivating the transport queue concept:
- Pull: Allow a client to see the possible request points;
- Push: When a client indicates an interest to receive the incremental
updates for a resource, the server can start to push incremental updates to
the client; the transport queue is a resource to tell a client the push
status and also reflect the push URI.


> Even with some guessing, I couldn't easily see how the non-push version is
> supposed to work.  How does the client know which URI to GET?  It looks
> like there is some magical URI construction going on based on examples, but
> that isn't written down.
>
>
We should update the whole workflow: The starting point is the Information
Resource Directory (IRD), which provides the entry point. We put the IRD
example in the later part and we can refer to it before the examples. How
does this sound?


> It looks like Section 8 is over-specifying, with details of stream
> dependencies and so forth.
>
>
Please see the generic email. We will try to simplify when we update. I see
two approaches to simplifying the spec: (1) let the application layer
handle it (each Ui as an independent message in the transport layer); and
(2) only specify the dependency of the resources but do not go to stream
dependency.


> I *think* there is a new resource type here, but that isn't registered in
> the IANA section.

That shouldn't be called "-h2"; a better name would describe what the
> resources are for.  There is also a new media type apparently, but I
> couldn't see where that is defined.
>
> Good catch. We have not included it yet as we are finalizing the semantics
and not the grammar yet, but it is a good point and the new version will
include the spec.

Thank you so much!

Richard



>
>
> On Mon, Jul 11, 2022, at 13:37, Mark Nottingham wrote:
> > Hi folks,
> >
> > I've been asked to forward this request for early review; does anyone
> > want to take a look?
> >
> > Feedback to alto@ietf.org.
> >
> > Cheers,
> >
> >
> >> Begin forwarded message:
> >>
> >> *From: *
> >> *Subject: **HTTP Review (draft-ietf-alto-new-transport)*
> >> *Date: *6 July 2022 at 12:56:56 am AEST
> >> *To: *Mark Nottingham 
> >> *Cc: *Qin Wu , "
> draft-ietf-alto-new-transp...@ietf.org" <
> draft-ietf-alto-new-transp...@ietf.org>
> >>
> >> The ALTO WG is currently working on the specification available at:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/. The
> current version focuses on H2 with the intent to cover at least common
> H2/H3 functionalities.
> >>
> >> The WG is seeking for early reviews so that issues/advice are taken
> into account early in the process.
> >>
> >> We are particularly interested in comments about the handling of H3,
> especially with regards to the 

[alto] alto transport streams (Re: early reviews)

[Y. Richard Yang]

Hi Mark, Martin, Spencer,

First, thank you so much for the reviews. Sorry for the delay in responding
asap, due to summer and travel.

One common comment we see from all three of you, in different texts, is
essentially on the service model of the current document (
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/): how much
control on the ordering of the messages (Mark/Martin), in-order or not
(Spencer). Hence, after the meeting early morning today, we feel that we
should start a single thread to discuss this issue. We will send a summary
of our responses to each of your individual reviews later.

To help make clear the problem and the current design, let's start by
summarizing the transport model of ALTO/SSE (RFC8895;
https://datatracker.ietf.org/doc/html/rfc8895). We will state the problem
as abstract as possible to see the essence of the problem and the potential
design choices:
- P1: A server offers multiple resources R = {R[1], R[2], R[3], R[4], ...},
where each R[i]i is represnted by a URI;
- P2: A client can request from the server the monitoring of a subset M of
the resources: M \subset R, e.g., M = {R[1], R[2], R[3]}; for example, R[1]
is a network map, R[2] is a cost map using the network map R[1], and R[3]
is an endpoint property map; for simplicity, assume the requested resources
numbered 1 to |M|

- P3: The server can push a sequence of incremental updates to the client
for each resource in M. Denote {U[i,1], U[i,2], ...} as the update sequence
from the server to the client for R[i] in M, where U[i,1] is the first
response for the requested resource R[i], U[i,2] is an incremental update
(patch) on top of U[i,1], U[i,3] is the incremental update on top of
U[i,2], ...

- P3.1: For flexibility, each U[i,j] can choose its own encoding; for
example, U[1,1] is application/alto-networkmap+json, U[1,2]
is application/merge-patch+json; concrete examples please see the current
draft (search "Promised Stream 4" and "Promised Stream 6")

- P4: Consider the dependency among the information resources in P3:
{U[1,1], U[1,2], ...}, {U[2,1], U[2,2], ...}, and {U[3,1], }. There are
two types:
- P4.1 We have that U[i,j+1] depends on U[i,j] due to incremental
updates---in the general case, the client needs to have received and
processed U[i,j] to apply U[i,j+1], unless U[i,j+1] is a snapshot (not an
incremental update).
- P4.2 It is possible that U[i', j'] depends on U[i, j], where i' != i: for
example, a cost map depends on the correct version of the network map.

If one goes academic, there is a dependency graph that can describe the
dependencies.

In RFC8895, since it is a single HTTP connection, all of the {U[i,j]} are
*linearized" by the server into a single sequence, and Section 6.7 of
RFC8895 specifies the linearization (serialization) requirements (P4.1 and
P4.2). As we know from concurrency control, linearization is strong and
leaves performance on the table. One of the motivations for the new
document is to take advantage of the more relaxed concurrency model allowed
by HTTP/2 and HTTP/3.

So what are the design points that the design team has considered:

- D1 (linearization): the server pushes all {U[i,j]} in a single stream.
Due to P3.1, there must be an internal structure to separate the U[i,j]
boundaries and different U[i,j] can have different media types, leading
back to RFC8895.

- D2 (max concurrency): Each U[i,j] is sent in an independent (concurrent)
push stream (and hence can use its own media type as it is) and let the
application-layer handles dependency: ALTO has a build-in dependency check
for cross-resource (P4.2) and the sequence numbers of incremental updates
allow application (ALTO client) to figure out the same-resource
dependency (P4.1). The application (ALTO client) buffers all streams to
realize the ordering.

- D3 (max concurrency with server barrier): It is D2 but requires that the
server does not push U[i',j'] if there is a U[i,j], s.t., (1) U[i,j] is
still being sent by the server to the client and (2) U[i',j'] depends on
U[i,j].

The intention of the current document is to reflect D3. Note that for D3,
the ALTO client still needs to handle the dependency correctly, as the
streams may be only buffered at the kernel, and not processed. But the
benefit of D3 over D2 is that it implements essentially some flow control,
to avoid a faster server overwhelming a slower client.

One design point that one may consider is
- D4 (linearization of same resource and concurrency for different
resources): the U[i,j] of the same R[i] is sent in the same stream (and
hence linearized); this can be a reasonable design, but due to P3.1, it is
still not clean; see D1 discussion.

I hope that the preceding has clarified the stream control issue that the
design faced. One can see that the issue can be considered as a generic
issue--what to specify when embedding one concurrency model (P4.1/P4.2)
into a given concurrency structure (HTTP/2 or HTTP/3). We took a quick look
at DoH. 

Re: [alto] Cellular information exposure discussion (Fwd: New Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

[Y. Richard Yang]

Hi Zili,

Thanks for the quick feedback! Please see below.

On Tue, Jul 19, 2022 at 12:18 PM Zili Meng  wrote:

> Hi Richard and all,
>
> Thanks for bringing this up!
>
> Sure we'll be very happy if we could contribute to the IETF and the alto
> group on how to feedback the network conditions (e.g., cellular
> information) to the application (the sender). And I also feel that a survey
> and a case study would be very helpful to sort out what we need in the
> scope of alto.
>

It looks that we are in agreement :-) I did a preliminary search, but do
not see a systematic survey. Such a survey can be an ietf work or an
independent work as a paper. We can wait for the guidance from the WG
chairs or AD.

As a starting point, I can see that the survey should include not only the
distribution methods (D-* in the previous email), which are potential
solutions, but also
- a list of benchmarking settings, including triggering events, such as the
bandwidth fluctuations that your work addresses;

- a list of use-case restriction or required features, such as
authentication (restriction), and carrier aggregation, which motivates the
W1 work;

- a list of performance metrics and their requirements, including those
application metrics and requirements discussed in MOWIE, and network
metrics (e.g., active users) and the requirements on their delivery by the
information channel.


> Unfortunately I may not be able to attend the alto meeting in IETF 114.
>

No problem at all. Email is a good starting point.

Do you feel it would be better if we first prepare some writeups or drafts
> for the C2 (send the network conditions back to the sender)? We could then
> bring writeups back on the design space and / or the use cases so that we
> can have something to discuss with.
>

Yes. See above. Let’s write the draft soon.

Richard

>


> A preprint of the W2 paper is available at
> https://zilimeng.com/papers/zhuge-sigcomm22.pdf for your information.
> We'll also be highly appreciated if there are any comments or feedback.
>
> On Tue, Jul 19, 2022 at 1:46 PM Y. Richard Yang 
> wrote:
>
>> Hi ALTO WG,
>>
>> During the weekly meeting today, the design team discussed about the
>> document, and suggested that the authors update the WG on a new version of
>> the MOWIE draft, which was uploaded last week and focuses on cellular
>> network information exposure to network-aware applications. The links to
>> the new version and the diff showing the updates can be found below. Any
>> comments, feedback, or interests in working together are welcome and
>> greatly appreciated.
>>
>> Using this email, we also want to include that there are two quite
>> relevant pieces of work:
>> W1. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer
>> Bandwidth Measurements (https://arxiv.org/abs/2002.03475), by Yaxiong
>> Xie, Prof. Jamieson, and Prof. Rexford;
>> W2. Achieving Consistent Low Latency for Wireless Real-Time
>> Communications with the Shortest Control Loop (paper to be made public
>> soon), by Zili, and Prof. Mingwei and team.
>>
>> It helps to use this email to point out a bigger picture of the problem
>> space and related work. One perspective is that the problem space consists
>> of 3 components:
>> C1. What cellular-network information should be collected to be sent to
>> the applications?
>> C2. How is the cellular information sent to the applications?
>> C3. How do the applications use the information?
>>
>> It is important to note that the full exploration of the problem space is
>> not included in the current charter. However, this is an important problem
>> space and hence it helps  to keep track of the progress and potential
>> impacts on ALTO.
>>
>> For C1, the impact will be the list of performance metrics. For C3, the
>> current ALTO charter does not include items to define application
>> behaviors, but it can be a point of discussion related to deployment.
>>
>> The most relevant component is C2. We discussed the following design
>> points for C2:
>> D-broadcast: network broadcasts its state
>> D-pass-bounce: network marks its state on pass-through packets and the
>> receiver bounces the state back to the sender
>> D-direct-send: network sends its state to app directly
>> Here by state it can be transformed state.
>>
>> Current ALTO is designed as D-direct-send. Due to lacking of deployment
>> of D-direct-send in cellular network, aforementioned W1 uses D-broadcast;
>> the D-pass-bounce design need at least a round trip time and couples
>> network feedback flow with data flow, leading to the aforementioned W2 work.
>>
>> Many of us feel that the t

Re: [alto] IETF 114 ALTO Hackathon projects

[Y. Richard Yang]

Hi all,

During the weekly ALTO meeting today, we discussed the coming hackathon and
Qin suggested that we send an update to the mailing list on the FTS+ALTO
project, and here is the update:

- In short, if you want to work on ALTO integration with production, open
projects, this can be a wonderful project to work on: it may help both ALTO
(in terms of its crucial deployment mandate) and the largest data-intensive
science projects at CERN.

Specifically:
- For those who have not tracked the hackathon, as Jordi said, it is a
continuation of the 113 Hackathon.  In particular, the 113 Hackathon
focused on the integration with Rucio, which is a wonderfully designed tool
used widely in CERN and some other projects for data movement of a large
amount of data (PB -> EB). In 113, the hackathon modified the manual
workflow, which is the workflow to select the source to download a dataset
when a client issues a download command. The other workflow of Rucio is the
automatic workflow, which selects the sources and destinations to realize
user-specified replication rules. In our original plan, 114 would focus on
the automatic workflow. However, the team realized that Rucio is built on
top of FTS, which is the main tool used at CERN to schedule which transfer
is scheduled at what time, where Rucio is at a higher layer providing the
transfers for FTS to schedule.

- The 114 hackathon includes 2 objectives: (1) introducing resource control
to FTS, and (2) evaluating an alternative design of FTS core: the FTS
Optimizer. Hence, the work includes 3 components, integrating the FTS
production code and framework:
(1/basic) allow FTS to specify resource control goal and use ALTO to map
FTS control state (called links in FTS, where a link is a pair consisting
of a source node to a destination node, where a node is called RSE) to
network state;
(2/basic) implement a full zero-order algorithm, to achieve fully
efficient, zero-order gradient control as FTS Optimizer;
(3/stretch) realize a composition framework to compose end-to-end resource
performance function, including both zero-order and first-order gradient,
covering the bottleneck structure.

The project is exciting both in terms of its technical content and also in
terms of its potential impacts. The hackathon project will work under the
guidance of the Rucio project lead (Dr. Mario Lassnig) and the FTS project
lead (Mihai Patrascoiu and Steven Murray); all cc'd in this email. This can
be a wonderful opportunity for IETF, the networked systems community and
the data-intensive sciences communities to work together.

Please feel free to reach out to us (Jordi, Mahdi and me) if you want to
join the hackathon or later.

Thanks,
Richard on behalf of the IETF 114 ALTO+FTS Hackathon Team

On Tue, Jul 12, 2022 at 1:14 AM Jordi Ros Giralt 
wrote:

> Hi all,
>
> I have uploaded to the IETF Hackathon Wiki the project description for
> ALTO. The proposed project is a natural evolution from the work done during
> the 113 Hackathon. I want to also thank and credit Jensen for providing the
> initial plan for the Hackathon.
>
> https://trac.ietf.org/trac/ietf/meeting/wiki/114hackathon
>
> You will also see that in addition to the ALTO hackathon, Ziyang will be
> leading a second project under the name "The SDN-based MPTCP-aware and
> MPQUIC-aware Transmission Control Model using ALTO". Many thanks Ziyang for
> leading this very interesting project too.
>
> Jordi
> On behalf of ALTO Hackathon group
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Cellular information exposure discussion (Fwd: New Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

[Y. Richard Yang]

Hi Med,

There are some efforts in 3GPP; the mowie draft discussed related 3GPP
efforts. I will let Tencent team (Yannis, Yixue, Yuhang) to give more info.
I do not believe there are related efforts in W2; that is, shorten the
feedback loop from passthrough-bounce to direct send. Zili can give an
update. I see that we need coordination with 3GPP, and we will reach out to
include those at 3GPP with related efforts and include them in the email
thread. Is this you would suggest?

Thanks!
Richard

On Tue, Jul 19, 2022 at 12:19 PM  wrote:

> Hi Richard,
>
>
>
> Thanks for this information.
>
>
>
> Just out of curiosity, are the proposed extensions currently discussed in
> the 3GPP?
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* alto  *De la part de* Y. Richard Yang
> *Envoyé :* mardi 19 juillet 2022 20:14
> *À :* IETF ALTO 
> *Objet :* [alto] Cellular information exposure discussion (Fwd: New
> Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt
>
>
>
>
>
> Hi ALTO WG,
>
>
>
> During the weekly meeting today, the design team discussed about the
> document, and suggested that the authors update the WG on a new version of
> the MOWIE draft, which was uploaded last week and focuses on cellular
> network information exposure to network-aware applications. The links to
> the new version and the diff showing the updates can be found below. Any
> comments, feedback, or interests in working together are welcome and
> greatly appreciated.
>
>
>
> Using this email, we also want to include that there are two quite
> relevant pieces of work:
> W1. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer
> Bandwidth Measurements (https://arxiv.org/abs/2002.03475), by Yaxiong
> Xie, Prof. Jamieson, and Prof. Rexford;
>
> W2. Achieving Consistent Low Latency for Wireless Real-Time Communications
> with the Shortest Control Loop (paper to be made public soon), by Zili, and
> Prof. Mingwei and team.
>
>
>
> It helps to use this email to point out a bigger picture of the problem
> space and related work. One perspective is that the problem space consists
> of 3 components:
>
> C1. What cellular-network information should be collected to be sent to
> the applications?
>
> C2. How is the cellular information sent to the applications?
>
> C3. How do the applications use the information?
>
>
>
> It is important to note that the full exploration of the problem space is
> not included in the current charter. However, this is an important problem
> space and hence it helps  to keep track of the progress and potential
> impacts on ALTO.
>
>
>
> For C1, the impact will be the list of performance metrics. For C3, the
> current ALTO charter does not include items to define application
> behaviors, but it can be a point of discussion related to deployment.
>
>
>
> The most relevant component is C2. We discussed the following design
> points for C2:
>
> D-broadcast: network broadcasts its state
>
> D-pass-bounce: network marks its state on pass-through packets and the
> receiver bounces the state back to the sender
>
> D-direct-send: network sends its state to app directly
>
> Here by state it can be transformed state.
>
>
>
> Current ALTO is designed as D-direct-send. Due to lacking of deployment of
> D-direct-send in cellular network, aforementioned W1 uses D-broadcast; the
> D-pass-bounce design need at least a round trip time and couples network
> feedback flow with data flow, leading to the aforementioned W2 work.
>
>
>
> Many of us feel that the time is ready for introducing a highly efficient,
> flexible channel for network state exposure to applications, led by IETF,
> and the ALTO team can be a good starting point. As a first step, a
> systematic evaluation, which (1) surveys the design space and (2)
> introduces the use cases/benchmarking scenarios, can be a good starting
> point.
>
>
>
> If there is time available in the coming 114 meeting, we can discuss more
> during the presentation. Otherwise, on-list discussion is a good starting
> point. We will follow up with more analysis on the list soon but use this
> email to get the conversation started.
>
>
>
> Thanks,
>
>
>
> Richard on behalf of Tuesday meeting team
>
>
>
>
>
>
>
> -- Forwarded message -
> From: 
> Date: Mon, Jul 11, 2022 at 2:14 PM
> Subject: New Version Notification for
> draft-huang-alto-mowie-for-network-aware-app-04.txt
> To: Y. Richard Yang , Gang Li <
> ligan...@chinamobile.com>, Sabine Randriamasy <
> sabine.randriam...@nokia-bell-labs.com>, Yixue Lei ,
> Yuhang Jia , Yunbo Han ,
> Y

[alto] Cellular information exposure discussion (Fwd: New Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

[Y. Richard Yang]

Hi ALTO WG,

During the weekly meeting today, the design team discussed about the
document, and suggested that the authors update the WG on a new version of
the MOWIE draft, which was uploaded last week and focuses on cellular
network information exposure to network-aware applications. The links to
the new version and the diff showing the updates can be found below. Any
comments, feedback, or interests in working together are welcome and
greatly appreciated.

Using this email, we also want to include that there are two quite relevant
pieces of work:
W1. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer
Bandwidth Measurements (https://arxiv.org/abs/2002.03475), by Yaxiong Xie,
Prof. Jamieson, and Prof. Rexford;
W2. Achieving Consistent Low Latency for Wireless Real-Time Communications
with the Shortest Control Loop (paper to be made public soon), by Zili, and
Prof. Mingwei and team.

It helps to use this email to point out a bigger picture of the problem
space and related work. One perspective is that the problem space consists
of 3 components:
C1. What cellular-network information should be collected to be sent to the
applications?
C2. How is the cellular information sent to the applications?
C3. How do the applications use the information?

It is important to note that the full exploration of the problem space is
not included in the current charter. However, this is an important problem
space and hence it helps  to keep track of the progress and potential
impacts on ALTO.

For C1, the impact will be the list of performance metrics. For C3, the
current ALTO charter does not include items to define application
behaviors, but it can be a point of discussion related to deployment.

The most relevant component is C2. We discussed the following design points
for C2:
D-broadcast: network broadcasts its state
D-pass-bounce: network marks its state on pass-through packets and the
receiver bounces the state back to the sender
D-direct-send: network sends its state to app directly
Here by state it can be transformed state.

Current ALTO is designed as D-direct-send. Due to lacking of deployment of
D-direct-send in cellular network, aforementioned W1 uses D-broadcast; the
D-pass-bounce design need at least a round trip time and couples network
feedback flow with data flow, leading to the aforementioned W2 work.

Many of us feel that the time is ready for introducing a highly efficient,
flexible channel for network state exposure to applications, led by IETF,
and the ALTO team can be a good starting point. As a first step, a
systematic evaluation, which (1) surveys the design space and (2)
introduces the use cases/benchmarking scenarios, can be a good starting
point.

If there is time available in the coming 114 meeting, we can discuss more
during the presentation. Otherwise, on-list discussion is a good starting
point. We will follow up with more analysis on the list soon but use this
email to get the conversation started.

Thanks,

Richard on behalf of Tuesday meeting team



-- Forwarded message -
From: 
Date: Mon, Jul 11, 2022 at 2:14 PM
Subject: New Version Notification for
draft-huang-alto-mowie-for-network-aware-app-04.txt
To: Y. Richard Yang , Gang Li <
ligan...@chinamobile.com>, Sabine Randriamasy <
sabine.randriam...@nokia-bell-labs.com>, Yixue Lei ,
Yuhang Jia , Yunbo Han , Yunfei
Zhang 



A new version of I-D, draft-huang-alto-mowie-for-network-aware-app-04.txt
has been successfully submitted by Y. Richard Yang and posted to the
IETF repository.

Name:   draft-huang-alto-mowie-for-network-aware-app
Revision:   04
Title:  MoWIE for Network Aware Applications
Document date:  2022-07-11
Group:  Individual Submission
Pages:  25
URL:
https://www.ietf.org/archive/id/draft-huang-alto-mowie-for-network-aware-app-04.txt
Status:
https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-huang-alto-mowie-for-network-aware-app
Diff:
https://www.ietf.org/rfcdiff?url2=draft-huang-alto-mowie-for-network-aware-app-04

Abstract:
   With the quick deployment of 5G networks in the world, cloud-based
   interactive applications (services) such as cloud gaming have gained
   substantial attention and are regarded as potential killer
   applications.  To ensure users' quality of experience (QoE), a cloud
   interactive service may require not only high bandwidth (e.g., high-
   resolution media transmission) but also low delay (e.g., low latency
   and low lagging).  However, the bandwidth and delay experienced by a
   mobile and wireless user can be dynamic, as a function of many
   factors, and unhandled changes can substantially compromise the
   user's QoE.  In this document, we investigate network-aware
   applications (NAA), which realize cloud based interactive services
   with improved QoE, by efficient utilization of a solution named
   Mobile and Wireless Informat

[alto] ALTO new transport discussion: Stream assignment

[Y. Richard Yang]

Hi ALToers, and experts on HTTP/2,

As we make progress on the transport document (
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/),  we have
one issue to discuss: stream management to take advantage of this HTTP/2
feature. Can we kindly ask that members read Section 8 of the document to
give us any feedback?

Thanks a lot,
Richard and Roland
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO meeting with PBE-CC team

[Y. Richard Yang]

Hi ALTO group,

We will meet with the PBE-CC team (Kyle Jamieson, Jen Rexford, and Yaxiong
Xie, all from Princeton) tomorrow at 9:00 AM US ET to discuss the
possibility of exposing more network information for applications.

The direct relevant paper is:
https://arxiv.org/abs/2002.03475

Another related work:
https://dl.acm.org/doi/pdf/10.1145/3405672.3409489

One "grand" scheme is network information exposure from control channel,
data channel, and control channel embedded in the data channel, e.g.,
https://datatracker.ietf.org/doc/rfc/

The meeting info is at the bottom of this page.

Looking forward to see the design team and more tomorrow.

- Richard on behalf of the meeting organizers

JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=ma0e97cc97c4cd71bb59cf1a094682686
Meeting number (access code): 2424 884 8159

Meeting password: ymKtkapb394

TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)
+1-650-479-3208,
,24248848159##
tel:%2B1-650-479-3208,,*01*24248848159%23%23*01* Call-in toll number
(US/Canada)

JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)

Global call-in numbers
https://ietf.webex.com/ietf/globalcallin.php?MTID=mb80643ae6bba4f3cf51f1b5918b3ce49

JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:24248848...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX29055

IMPORTANT NOTICE: Please note that this Webex service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you automatically
consent to such recordings. If you do not consent to being recorded,
discuss your concerns with the host or do not join the session.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO presentation at WLCG DOMA on April 27, 2022

[Y. Richard Yang]

Hi all,

Some of us will make a presentation on ALTO at the DOMA (Data Organization,
Management and Access) Group of WCLG (World-Wide LHC Computing Grid) on
Wednesday. The goal is to further (1) drive the implementation of openalto
and (2) integrate ALTO into Rucio and FDS. Anyone with an interest is
welcome to work with us and please just send us a note.

Thanks,
Jordi and Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-performance-metrics-26: (with COMMENT)

[Y. Richard Yang]

Hi Éric,

Thank you so much for the update.

For the comment on IPv4: we had some discussions on how to address it. In
earlier documents, we used a mix of IPv4 and IPv6 addresses (e.g., an
earlier version of RFC7285 used a mix of ipv4 and ipv6 in examples such as
https://datatracker.ietf.org/doc/html/rfc7285#section-11.5.1.7), and the
feedback was that this could be confusing, and hence we used only ipv4
addresses. We see two possibilities: (1) add one example, say replicating
Example 1, but with ipv6; and (2) change one of the late examples, say
example 2, from ipv4 to ipv6 addresses.

For the TCP model, the examples we gave (
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-26#section-4.1)
mentioned both Cubic and BBR. Does this address the comment? Or the
suggestion is to change the metric from "TCP Throughput" to something like
"Congestion Control Throughput" to be more general?

Please let us know and we sure can take a pass.

Thank you so much again!
Richard

On Fri, Mar 4, 2022 at 5:57 AM Éric Vyncke via Datatracker 
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-alto-performance-metrics-26: 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/about/groups/iesg/statements/handling-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/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for addressing my previous DISCUSS point, I have now updated my
> ballot position into a NO OBJECT.
>
> Nevertheless, I would have appreciated a reaction on the IPv4-only
> examples and
> the focus on TCP only but this is obviously not blocking this document. I
> appreciate that my other comments were used to improve the document.
>
> Regards
>
> -éric
>
> —— below is for archiving only —
>
> 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
>
> == 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] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)

[Y. Richard Yang]

Hi Zahed,

Thanks for the good catch. Can you please take a look at -26 and let us
know.

Thanks again!
Richard

On Wed, Mar 2, 2022 at 6:38 AM Qin Wu  wrote:

> Good catch, Zahed, authors have issued v-26 to fix this issue.
>
> See the diff:
>
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-26.txt
>
> *发件人:* Zaheduzzaman Sarker [mailto:zaheduzzaman.sar...@ericsson.com]
> *发送时间:* 2022年3月2日 18:30
> *收件人:* Y. Richard Yang 
> *抄送:* Qin Wu ; The IESG <
> i...@ietf.org>; alto-cha...@ietf.org;
> draft-ietf-alto-performance-metr...@ietf.org; alto@ietf.org
> *主题:* Re: [alto] Zaheduzzaman Sarker's Discuss on
> draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)
>
>
>
> Thanks for the updates.
>
>
>
> I however, didn’t notice the change in section 2.2 egarding JSON number
> format, which previously was agreed to be changed, in the 25th of this
> document.
>
>
>
> //Zahed
>
>
>
>
>
>
>
> On 28 Feb 2022, at 22:14, Y. Richard Yang  wrote:
>
>
>
> Hi Zaheduzzaman,
>
>
>
> We have posted the latest version of the document:
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-24
>
>
>
> Could you please take a look to see if all of your comments are addressed?
> In particular,
> - We checked and made sure that the normative references are correct.
>
> - We updated the abstract to clarify the wording and added sentences in
> Sec. 1 on the uses.
>
> - We revised the final wording of 2.2 on the number format
>
> - We checked all json examples and fixed the issues.
>
>
>
> Please take a look and let us know if there are remaining issues to
> be addressed.
>
>
>
> Thank you so much!
>
> Richard
>
>
>
> On Thu, Dec 2, 2021 at 8:32 AM Qin Wu 
> wrote:
>
> Hi, Zaheduzzaman:
> -邮件原件-
> 发件人: Zaheduzzaman Sarker via Datatracker [mailto:nore...@ietf.org]
> 发送时间: 2021年12月2日 19:35
> 收件人: The IESG 
> 抄送: draft-ietf-alto-performance-metr...@ietf.org; alto-cha...@ietf.org;
> alto@ietf.org; i...@j-f-s.de; i...@j-f-s.de
> 主题: Zaheduzzaman Sarker's Discuss on
> draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-alto-performance-metrics-20: 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:
> --
>
> I perhaps understand the intention of extending the ALTO protocol so that
> the ALTO client and server have defined way of exchanging values for
> already defined metrics. However, I need to agree with my fellow AD
> colleagues that this document need to describe why those metrics are needed
> and describe the relationship with other RFCs those defines those metrics
> mostly for other contexts. To that end all the RFCs in the Table 1 in
> section 1 need to be normative references.
>
> [Qin Wu] I think the key use case is defined in RFC7752 section 2.2, i.e.,
> export BGP-LS collected topology data to ALTO server and the ALTO server
> expose data to the client. RFC8571 provides additional performance metric
> related data which is part of topology data. Most of performance cost
> metrics derived from metrics defined in RFC8571.
> Another two relevant use cases are documented in section 3 of
> draft-xie-alto-lmap-00, one is targeted to network operators who need to
> understand the performance of their networks, the performance of the
> suppliers (downstream and upstream networks), the performance of Internet
> access services, and the impact that such performance has on the experience
> of their customers.
> The other is targeted to regulators who want to evaluate the performance
> of the network services offered by operators.
> --
> COMMENT:
> --
>
> Thanks for the work on this document and thanks to Brian Trammell for his
> TSVART early review.
>
> I have following comments which I believe will improve the document
> quality -
>
> 1. I

[alto] ALTO transport discussion thread

[Y. Richard Yang]

Hi ALTOers,

Several of us (Roland, Kai, me) are working on ALTO transport, and our plan
is to update a relatively complete version by the draft deadline of March 7
(one week from today).

Here is a brief summary of current design points:
- It will be RESTful, as the current design
- It will redesign ALTO SSE functions by introducing update queues so that
(1) the server can organize incremental updates into the queues; (2) the
server can push updates to the client using the queue URI (to be consistent
with HTTP/2 PUSH_PROMISE semantics); and (3) the client can request content.

The main remaining issue that we will finalize is how to allow clients to
rejoin, and we will finalize the initial design soon. All are welcome to
join to work together.

Thanks,
Richard and Roland
___
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)

[Y. Richard Yang]

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  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  40huawei@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-boun...@ietf.org] *代表 *Martin Duke
>> *发送时间:* 2021年12月20日 23:27
>> *收件人:* Eric Vyncke (evyncke) 
>> *抄送:* alto-chairs ;
>> draft-ietf-alto-performance-metr...@ietf.org; The IESG ;
>> IETF ALTO 
>> *主题:* 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 
>> 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
>> <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 
>> *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:
>> 

Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)

[Y. Richard Yang]

Hi Zaheduzzaman,

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

Could you please take a look to see if all of your comments are addressed?
In particular,
- We checked and made sure that the normative references are correct.
- We updated the abstract to clarify the wording and added sentences in
Sec. 1 on the uses.
- We revised the final wording of 2.2 on the number format
- We checked all json examples and fixed the issues.

Please take a look and let us know if there are remaining issues to
be addressed.

Thank you so much!
Richard

On Thu, Dec 2, 2021 at 8:32 AM Qin Wu 
wrote:

> Hi, Zaheduzzaman:
> -邮件原件-
> 发件人: Zaheduzzaman Sarker via Datatracker [mailto:nore...@ietf.org]
> 发送时间: 2021年12月2日 19:35
> 收件人: The IESG 
> 抄送: draft-ietf-alto-performance-metr...@ietf.org; alto-cha...@ietf.org;
> alto@ietf.org; i...@j-f-s.de; i...@j-f-s.de
> 主题: Zaheduzzaman Sarker's Discuss on
> draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)
>
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-alto-performance-metrics-20: 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:
> --
>
> I perhaps understand the intention of extending the ALTO protocol so that
> the ALTO client and server have defined way of exchanging values for
> already defined metrics. However, I need to agree with my fellow AD
> colleagues that this document need to describe why those metrics are needed
> and describe the relationship with other RFCs those defines those metrics
> mostly for other contexts. To that end all the RFCs in the Table 1 in
> section 1 need to be normative references.
>
> [Qin Wu] I think the key use case is defined in RFC7752 section 2.2, i.e.,
> export BGP-LS collected topology data to ALTO server and the ALTO server
> expose data to the client. RFC8571 provides additional performance metric
> related data which is part of topology data. Most of performance cost
> metrics derived from metrics defined in RFC8571.
> Another two relevant use cases are documented in section 3 of
> draft-xie-alto-lmap-00, one is targeted to network operators who need to
> understand the performance of their networks, the performance of the
> suppliers (downstream and upstream networks), the performance of Internet
> access services, and the impact that such performance has on the experience
> of their customers.
> The other is targeted to regulators who want to evaluate the performance
> of the network services offered by operators.
> --
> COMMENT:
> --
>
> Thanks for the work on this document and thanks to Brian Trammell for his
> TSVART early review.
>
> I have following comments which I believe will improve the document
> quality -
>
> 1. In the abstract I read about "a better delay performance" and was
> hoping it will be clear to me what is "a better delay performance".
> Unfortunately, I was unable to get that. This comes to the point that this
> document needs to describe why purpose of using the defined metrics well.
> [Qin Wu] See clarification above.
>
> 2. Section 2.2 says
>
> The number MUST be a non-negative JSON integer in the range [0, 100]
> (i.e.,
> greater than or equal to 0 and less than or equal to 100), followed by
> an
> optional decimal part, if a higher precision is needed.
>
>   This should be a JSON number type not integer type.
> [Qin Wu] See clarification to Ben's comments. The format of percentile is
> integer number followed by optional decimal part starting with the '.'
> separator.
> 3. There are number of broken JSON examples. for example, in section 4.2.3
> "ipv4:192.0.2.2" {
>   "ipv4:192.0.2.89" :0,
>   "ipv4:198.51.100.34": 2000
> }
>missing ":" after  ipv4:192.0.2.2
> [Qin Wu] Agree to fix this.
> 4. Content-Length: TBA in the examples, I actually don't know how to
> interpret it.
>
> [Qin Wu] Agree to fix this.
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-performance-metrics-21: (with DISCUSS)

[Y. Richard Yang]

Hi Francesca,

We have fixed the issues:
- The extra addition of bw-utilized is removed.
- We have fixed the second issue.

The latest version is at:
https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/23/

Could you please take a look and let us know if the revised version is OK?

Thank you so much for the wonderful reviews!

Richard


On Wed, Jan 5, 2022 at 1:49 PM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

> Francesca Palombini 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 the work on this document, and for addressing my previous
> DISCUSS
> points. I noticed two additional JSON issue, easy to fix, reported below.
>
> Many thanks to Christian Amsüss for his review:
> https://mailarchive.ietf.org/arch/msg/art/owYhcoFnl1vEipZ2D62cWiiE-LA/ ,
> and
> thanks to the authors for addressing it.
>
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion; I really think that the
> document would be improved with a change here, but can be convinced
> otherwise.
>
> Francesca
>
> 1. -
>
> Section 4.4.3
>
>{
>  "cost-type" { "cost-mode":   "numerical",
>"cost-metric": "bw-utilized"},
>  "endpoints":  {
> "srcs": [ "ipv4 : 192.0.2.2" ],
> "dsts": [
>"ipv4:192.0.2.89",
>"ipv4:198.51.100.34"
> ]
>  }
>}
>
> FP: JSON doesn't validate: missing ":" after "cost-type".
>
> 2. -
>
> Section 4.3.3.
>
>{
>  "cost-type" { "cost-mode":   "numerical",
>"cost-metric": "bw-available"},
>  "endpoints":  {
> "srcs": [ "ipv4 : 192.0.2.2" ],
> "dsts": [
>"ipv4:192.0.2.89",
>"ipv4:198.51.100.34"
> ]
>  }
>}
>
> FP: JSON doesn't validate: missing ":" after "cost-type". (Minor note - is
> there a reason why the "srcs" address has whitespaces while other addresses
> don't? 3 occurrences in the text).
>
>
>
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Y. Richard Yang]

Hi Ben,

Sorry for the late reply. We have uploaded a new version to address your
wonderful comments, and the latest version is at:
https://www.ietf.org/staging/draft-ietf-alto-performance-metrics-23.html

Summary of main changes:
- For your comment (1), we have recomputed the Content-Length. Could you
please take a look?
- For your comment (2), we have removed the extra addition of bw-utilized.
It was added to be as matching IS-IS, OSPF, BGP-LS as possible but this is
too late stage to do so.
- For the change of delay-ow and delay-rt semantics from milliseconds to
microseconds, it is exactly what you said, to be consistent with the TE
metrics.
- Section 3.3.3 comment. It is excellent. We have changed to "A
non-normative reference definition of end-to-end one-way delay variation is
. Note that  allows the
specification of a generic selection function F to unambiguously define the
two packets selected to compute delay variations. This document defines the
specific case that F selects as the "first" packet the one with the
smallest one-way delay." The staging version has a small issue and we fixed
in the version that we are using right now.
- Sec. 3.4.4. we changed to "For estimation by aggregation of routing
protocol link metrics, the default aggregation of the average of loss rate
is the sum of the link link loss rates. But this default aggregation is
valid only if two conditions are met: (1) it is valid only when link loss
rates are low, and (2) it assumes that each link's loss events are
uncorrelated with every other link's loss events. When loss rates at the
links are high but independent, the general formula for aggregating loss
assuming each link is independent is to compute end-to-end loss as one
minus the product of the success rate for each link. Aggregation when
losses at links are correlated can be more complex and the ALTO server
should be cognizant of correlated loss rates."

The two nits are fixed as well.

We cannot appreciate more the wonderful reviews and suggestions!!

Richard

On Fri, Jan 28, 2022 at 2:38 PM Benjamin Kaduk  wrote:

> Hi Richard,
>
> On Tue, Dec 21, 2021 at 08:13:02PM -0500, Y. Richard Yang wrote:
> > Hi Ben,
> >
> > Thank you so much for the wonderful, fast, thorough reviews! I understand
> > that Qin has already sent a reply and please see below.
>
> Yes, Qin's reply was quite helpful -- thanks, Qin!
>
> > On Mon, Dec 20, 2021 at 7:58 PM Benjamin Kaduk via Datatracker <
> > nore...@ietf.org> wrote:
> >
> > > 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).)
> > >
> > >
> > Th

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

[Y. Richard Yang]

Hi Lars,

Thank you for your feedback and we have made changes to the alto
performance metrics. The latest version is posted at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-22

Could you please take a look to see if we have addressed your comments? At
a high level,
- We tried to clarify where the metrics come from. The related text is on
page 5 and 6.
- One part which we want you to check is tput. The section is at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-22#section-4.1

Greatly appreciate the wonderful reviews!
Richard

On Tue, Nov 30, 2021 at 9:27 PM Y. Richard Yang  wrote:

> Hi Lars,
>
> Just posted an updated version, and a diff from the previous version is
> available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-20
>
> Thanks!
> Richard
>
> On Tue, Nov 30, 2021 at 8:49 PM Y. Richard Yang  wrote:
>
>> Hi Lars,
>>
>> Thanks for the review! Please see below.
>>
>> On Mon, Nov 29, 2021 at 8:10 AM Lars Eggert via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>> Lars Eggert has entered the following ballot position for
>>> draft-ietf-alto-performance-metrics-19: Discuss
>>>
>>> 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:
>>> --
>>>
>>> This document needs to become much more formal about how it defines the
>>> metrics it wishes to use with ALTO. This could either be done either by
>>> identifying and normatively referencing existing metrics the IETF has
>>> defined,
>>> or by defining them here. When normatively referencing existing IETF
>>> metrics, it
>>> would need to explain why their use with ALTO makes sense.
>>>
>>> At the moment, the document informatively points to a somewhat arbitrary
>>> collection of prior IETF metrics (most of which are from IPPM, residual
>>> bandwidth from IS-IS TE, but then reservable bandwidth from OSPF TE?).
>>
>>
>> To give some background, the WG derived the list of metrics from RFC 8571
>> (BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering
>> Performance
>> Metric Extensions), focusing on network->application. The list added Hop
>> Count
>> (exists in original ALTO RFC 7285), Round-trip (to avoid two queries, and
>> many apps
>> use RTT), and TCP Throughput, and removed Unidirectional Available
>> Bandwidth
>> and Unidirectional Utilized Bandwidth, to reduce the number of bandwidth
>> metrics.
>>
>>
>>> But it
>>> only refers to them as "examples",
>>
>>
>> I searched the word "example" and do not see where the document says that
>> they
>> are examples. It says that "Since different applications may use
>> different cost metrics,
>> the ALTO base protocol introduces an ALTO Cost Metric Registry (Section
>> 14.2 of
>> [RFC7285]), as a systematic mechanism to allow different metrics to be
>> specified. For
>> example, a delay-sensitive application may want to use latency-related
>> metrics, and
>> a bandwidth-sensitive application may want to use bandwidth-related
>> metrics."
>>
>> Does this paragraph give an impression that the metrics are only
>> examples? If so,
>> do you suggest removing the "For example" phrase to reduce the impression?
>>
>> The document does have the sentence " The "Origin Example" column of
>> Table
>> 1 gives an example RFC that has defined each metric." Here the word
>> "example"
>> word means one existing work.
>>
>>
>>> without actually defining how exactly they
>>> are to be used with ALTO, or - if not those - which actual metrics are
>>> supposed
>>> to be used.
>>>
>>
>> The document has "... the ALTO base protocol introduces an ALTO Cost
>> Metric Registry
>> (Section 14.2 of [RFC7285]), as a systematic mechanism to allow different
>> metrics
>>  to be specified. " and "When an ALTO server supports a cost metric
>> defined in this document,
>>

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

[Y. Richard Yang]

Hi Ben,

Thank you so much for the wonderful, fast, thorough reviews! I understand
that Qin has already sent a reply and please see below.

On Mon, Dec 20, 2021 at 7:58 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> 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).)
>
>
This is very helpful and we are impressed! Below is the method that we are
finally using:
copy .json file to a text file, e.g., example1-req.json
{
  "cost-type" : {"cost-mode"   : "numerical",
 "cost-metric" : "delay-ow"},
  "endpoints" : {
"srcs" : [ "ipv4:192.0.2.2" ],
"dsts" : [
  "ipv4:192.0.2.89",
  "ipv4:198.51.100.34"
]
  }
}

Issue a curl request to example.com:
curl -v --http1.1 -X POST -H 'Content-Type: application/json' --crlf
--data-binary @$i example.com 2>&1 -o /dev/null | grep -Fi '>
Content-Length'

Note that it sets http/1.1, and asks curl to fix the crlf issue (I am using
a mac and hence have 0x0a). Note $i is the input file. For example, for the
updated example1-req.json, we get 225. Is it consistent with your method?


> (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."
>

Good comment. I see where the potential confusion can be. How about the
following change to make clear the definition of utilized bandwidth for a
path?
"The base semantics of the metric is the Unidirectional Utilized Bandwidth
metric defined in [RFC8571,RFC8570,RFC7471], but instead of specifying the
utilized bandwidth for a link, it is the utilized bandwidth of the path
from the source to the destination, where the utilized bandwidth of the
path from the source to the destination is defined as the maximum utilized
bandwidth among all links from the source to the destination."

Overall, I agree that we should not add bw-utilized to be fully consistent,
and we will just reverted bw-utilized.



>
> --
> 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.
>
>
It is wonderful that you caught it immediately. The reason chain was
the perfect consistency, but it is not a good idea. So we will just drop
this new metric.



> Section 3.1.2, 3.2.2
>
> I see that the delay-ow and delay-rt semantics have been changed from
> 

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

[Y. Richard Yang]

ENT:
> --
>
> == 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
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Y. Richard Yang]

Hi Ben,

Thank you so much for the wonderful review and we have taken a pass of the
document. One quick question: should we upload a newer version (v21) so
that you can check the detailed edits using diff or you prefer we post the
revised text inline in reply?

Thank you so much!
Richard


On Wed, Dec 8, 2021 at 6:43 PM Benjamin Kaduk  wrote:

> Hi Qin,
>
> It looks like the only topic that's potentially unresolved is the BCP 18
> question.  I think internationalization is a topic where we mostly look to
> the ART ADs for guidance, and I'm reluctant to claim any kind of authority
> on the "right thing to do".  Mostly I wanted to raise the topic for
> visibility in case anyone else had any thoughts; if no one else replies, I
> think the authors should do what they feel best (which could include making
> no change to the draft).
>
> Thanks,
>
> Ben
>
> On Mon, Dec 06, 2021 at 01:25:20PM +, Qin Wu wrote:
> > Hi, Ben:
> > -邮件原件-
> > 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Benjamin Kaduk
> > 发送时间: 2021年12月4日 6:30
> > 收件人: Qin Wu 
> > 抄送: draft-ietf-alto-performance-metr...@ietf.org; alto@ietf.org; The
> IESG ; Y. Richard Yang ;
> alto-cha...@ietf.org
> > 主题: Re: [alto] Benjamin Kaduk's Discuss on
> draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)
> >
> > Hi Qin,
> >
> > On Thu, Dec 02, 2021 at 09:04:18AM +, Qin Wu wrote:
> > > Thanks Ben for detailed valuable review, see reply and clarification
> below.
> > >
> > > -邮件原件-
> > > >发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> > > >发送时间: 2021年12月2日 13:05
> > > >收件人: The IESG 
> > > >抄送: draft-ietf-alto-performance-metr...@ietf.org;
> > > >alto-cha...@ietf.org; alto@ietf.org; i...@j-f-s.de; i...@j-f-s.de
> > > >主题: Benjamin Kaduk's Discuss on
> > > >draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)
> > >
> > > >Benjamin Kaduk has entered the following ballot position for
> > > >draft-ietf-alto-performance-metrics-20: 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:
> > > >-
> > > >-
> > >
> > > >These should all be trivial to resolve -- just some minor internal
> inconsistencies that need to be fixed before publication.
> > >
> > > >The discussion of percentile statistical operator in §2.2 is
> internally inconsistent -- if the percentile number must be an integer,
> then p99.9 is not valid.
> > > [Qin Wu] Yes, the percentile is a number following the letter 'p', but
> > > in some case when high precision is needed, this percentile number
> will be further followed by an optional decimal part The decimal part
> should start with the '.' separator. Maybe the separator cause your
> confusion. See definition in section 2.2 for details:
> > > "
> > >percentile, with letter 'p' followed by a number:
> > >   gives the percentile specified by the number following the letter
> > >   'p'.  The number MUST be a non-negative JSON integer in the range
> > >   [0, 100] (i.e., greater than or equal to 0 and less than or equal
> > >   to 100), followed by an optional decimal part, if a higher
> > >   precision is needed.  The decimal part should start with the '.'
> > >   separator (U+002E), and followed by a sequence of one or more
> > >   ASCII numbers between '0' and '9'.
> > > "
> > > Let us know if you think separator should be changed or you live with
> the current form.
> >
> > Oops, that's my mistake and you are correct.  Sorry about that; I agree
> that no change is needed here.
> >
> > [Qin Wu] Great, thanks.
> > > >Also, the listing of "

Re: [alto] New chair!

[Y. Richard Yang]

Thank you so much for the wonderful work by Jan. You will be greatly
missed!!

To Med: Welcome to the ALTO team!

To ALTOers, please scroll to the last line of IETF documents stat :-)
https://datatracker.ietf.org/stats/document/author/documents/

Richard

On Tue, Dec 7, 2021 at 8:59 AM Jensen Zhang 
wrote:

> Welcome Med!
>
> And thanks to Jan for your past work.
>
> Jensen
>
>
> On Tue, Dec 7, 2021 at 9:46 PM  wrote:
>
>> Welcome Med! Looking forward to working with you!
>>
>>
>> Thanks Jan!
>>
>>
>> Best,
>>
>> Kai
>>
>>
>> -Original Messages-
>> *From:*"LUIS MIGUEL CONTRERAS MURILLO" <
>> luismiguel.contrerasmuri...@telefonica.com>
>> *Sent Time:*2021-12-07 21:31:06 (Tuesday)
>> *To:* "Qin Wu" , "Martin Duke" <
>> martin.h.d...@gmail.com>, "IETF ALTO" 
>> *Cc:*
>> *Subject:* Re: [alto] New chair!
>>
>> Congrats Med!
>>
>>
>>
>> and thanks Jan for your work along these past years.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Luis
>>
>>
>>
>> *De:* alto  *En nombre de *Qin Wu
>> *Enviado el:* martes, 7 de diciembre de 2021 14:25
>> *Para:* Martin Duke ; IETF ALTO 
>> *Asunto:* Re: [alto] New chair!
>>
>>
>>
>> Welcome Med! Wonderful to have you.
>>
>> Thanks all the other volunteers, look forward to continue to work with
>> you as a team.
>>
>> And also express my thanks to Jan, in advance, for his service as ALTO
>> chair.
>>
>>
>>
>> -Qin
>>
>> *发件人**:* alto [mailto:alto-boun...@ietf.org ] *
>> 代表 *Martin Duke
>> *发送时间:* 2021年12月7日 1:57
>> *收件人:* IETF ALTO 
>> *主题:* [alto] New chair!
>>
>>
>>
>> Hello ALTO,
>>
>>
>>
>> I'd like to welcome Mohamed Boucadair, of Orange, as the new ALTO chair.
>> This frees Jan to step down at his convenience. When he chooses to do so,
>> we'll thank him properly.
>>
>>
>>
>> Mohamed has not been intimately involved with ALTO, but he will bring
>> significant IETF experience and an operator's perspective to the role.
>> Thanks for serving, Mohamed!
>>
>>
>>
>> I'd also like to thank the other candidates. We were blessed with several
>> volunteers who all would have done a fine job, and it was hard to pick from
>> them.
>>
>>
>>
>> Martin
>>
>> --
>>
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
>> puede contener información privilegiada o confidencial y es para uso
>> exclusivo de la persona o entidad de destino. Si no es usted. el
>> destinatario indicado, queda notificado de que la lectura, utilización,
>> divulgación y/o copia sin autorización puede estar prohibida en virtud de
>> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>> destrucción.
>>
>> The information contained in this transmission is privileged and
>> confidential information intended only for the use of the individual or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any dissemination, distribution or
>> copying of this communication is strictly prohibited. If you have received
>> this transmission in error, do not read it. Please immediately reply to the
>> sender that you have received this communication in error and then delete
>> it.
>>
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>> destinatário, pode conter informação privilegiada ou confidencial e é para
>> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o
>> destinatário indicado, fica notificado de que a leitura, utilização,
>> divulgação e/ou cópia sem autorização pode estar proibida em virtude da
>> legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos
>> o comunique imediatamente por esta mesma via e proceda a sua destruição
>>
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IESG evaluation results

[Y. Richard Yang]

Hi Martin,

Add the WG, so that we can hear others' comments as well. Please see below
for a small addition.

On Fri, Dec 3, 2021 at 1:46 PM Y. Richard Yang  wrote:

> Martin,
>
> Thanks a lot for the update! A quick reply on performance metrics.
>
> On Fri, Dec 3, 2021 at 1:22 PM Martin Duke 
> wrote:
>
>>
>> 2) We will have to do something about performance-metrics. In the
>> telechat, we agreed that metrics collection is out of scope.
>>
>
> Not sure I understand what metrics collection refers to. Could you please
> add a bit of detail?
>
>
>> However, more precise definitions of these metrics are in scope. I would
>> suggest finding RFCs in the ippm WG stream that contain useful definitions
>> and using those.
>>
>
> Going down the path ippm can lead to potential issues. The current metrics
> definitions are more based on deriving path metrics from link metrics
> reported in the routing system (e.g., BGP-LS). This is how current
> deployment (e.g., Flow Director, Lui's team) works and hence is proven to
> be feasible. I do not see that the routing systems will start to ask
> routing devices to measure link properties using ippm measurements, and
> then report using routing protocols. Then conforming to ippm measurement
> metrics can lead to higher deployment barriers. We sure can take a look but
> want to point out the potential problem first.
>
>
Almost all metrics are derived from BGL-LS metrics (RFC8571). Hence, it is
not clear what more precise definitions mean. Does it mean that those
definitions in RFC8571 (which are defined in IGP existing IGP protocols)
are not precise, and hence should not be used (and hence switch to ippm
type of metrics, which specify many more parameters such as traffic
patterns)? Or it means that the performance metric document should just
make a single reference, and the IGP metrics as already defined by IETF are
acceptably "precise".

Or maybe it is only about the tput metric, and if so, we can discuss it
carefully.

Thanks a lot,
Richard






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

Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS)

[Y. Richard Yang]

Hi Francesca,

Thank you so much for the review! Please see inline.

On Wed, Dec 1, 2021 at 4:57 PM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-alto-performance-metrics-20: 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 on this document.
>
> Many thanks to Christian Amsüss for his review:
> https://mailarchive.ietf.org/arch/msg/art/owYhcoFnl1vEipZ2D62cWiiE-LA/ ,
> and
> thanks to the authors for addressing it.
>
> I am holding a DISCUSS to make sure the examples are fixed before
> publication.

Additionally, I agree with Christian that the line "Content-Length: TBA" in
> all
> the examples is not really helpful to the reader, and I suggest to either
> remove it or replace TBA with the actual content length for each example.
>
>
Thank you for the reminder. We will double-check that the examples are
fixed. In our
updated version---to be uploaded soon, will use the actual content length,
to be
conforming to HTTP.


> Francesca
>
> 1. -
>
> {
>"meta": {
>   "cost type": {
> "cost-mode": "numerical",
> "cost-metric":"hopcount"}
>   }
>},
>   "endpoint-cost-map": {
>   "ipv4:192.0.2.2": {
>   "ipv4:192.0.2.89"   : 5,
>   "ipv4:198.51.100.34": 3
>  }
>}
> }
>
> FP: JSON doesn't validate. There is one "}" too many after "hopcount".
>

Thank you for catching it. It is fixed in the running version.


>
> 2. -
>
>{
>  "meta": {
> "cost type": {
>"cost-mode": "numerical",
>"cost-metric":"tput"
>}
>  }
>  "endpoint-cost-map": {
>"ipv4:192.0.2.2": {
>  "ipv4:192.0.2.89"   : 256000,
>  "ipv4:198.51.100.34": 128000
>  }
>}
>
> FP: JSON doesn't validate. I believe there is 2 errors: after the second
> "}"
> after "tput" there is a missing "," , and it is also missing a final "}"
> at the
> end.
>
> Yep. You are right and they are fixed.


> 3. -
>
> {
>  "meta": {
>"cost-type" {
>  "cost-mode": "numerical",
>  "cost-metric": "bw-residual"
>}
>  },
>  "endpoint-cost-map" {
>"ipv4:192.0.2.2" {
>  "ipv4:192.0.2.89" :0,
>  "ipv4:198.51.100.34": 2000
>}
>  }
>}
>
> FP: JSON doesn't validate - there is a bunch of missing ":" all over.
>
>
Fixed.


> 4. -
>
> {
>"cost-type" { "cost-mode":   "numerical",
>  "cost-metric": "bw-maxres"},
>"endpoints":  {
>  "srcs": [ "ipv4 : 192.0.2.2" ],
>  "dsts": [
>"ipv4:192.0.2.89",
>"ipv4:198.51.100.34"
>  ]
>}
>  }
>
> FP: JSON doesn't validate: missing ":" after "cost-type"
>
> Got it and fixed.


> 5. -
>
> {
>  "meta": {
>"cost-type": {
>  "cost-mode":   "numerical",
>  "cost-metric": "bw-maxres"
>}
>  },
>  "endpoint-cost-map": {
>"ipv4:192.0.2.2" {
>  "ipv4:192.0.2.89" :0,
>  "ipv4:198.51.100.34": 2000
>}
>  }
>}
>
> FP: JSON doesn't validate: missing ":" after "ipv4:192.0.2.2"
>
> Fixed.
>

Thank you so much!
Richard


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

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

[Y. Richard Yang]

Hi Lars,

Just posted an updated version, and a diff from the previous version is
available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-20

Thanks!
Richard

On Tue, Nov 30, 2021 at 8:49 PM Y. Richard Yang  wrote:

> Hi Lars,
>
> Thanks for the review! Please see below.
>
> On Mon, Nov 29, 2021 at 8:10 AM Lars Eggert via Datatracker <
> nore...@ietf.org> wrote:
>
>> Lars Eggert has entered the following ballot position for
>> draft-ietf-alto-performance-metrics-19: Discuss
>>
>> 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:
>> --
>>
>> This document needs to become much more formal about how it defines the
>> metrics it wishes to use with ALTO. This could either be done either by
>> identifying and normatively referencing existing metrics the IETF has
>> defined,
>> or by defining them here. When normatively referencing existing IETF
>> metrics, it
>> would need to explain why their use with ALTO makes sense.
>>
>> At the moment, the document informatively points to a somewhat arbitrary
>> collection of prior IETF metrics (most of which are from IPPM, residual
>> bandwidth from IS-IS TE, but then reservable bandwidth from OSPF TE?).
>
>
> To give some background, the WG derived the list of metrics from RFC 8571
> (BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering
> Performance
> Metric Extensions), focusing on network->application. The list added Hop
> Count
> (exists in original ALTO RFC 7285), Round-trip (to avoid two queries, and
> many apps
> use RTT), and TCP Throughput, and removed Unidirectional Available
> Bandwidth
> and Unidirectional Utilized Bandwidth, to reduce the number of bandwidth
> metrics.
>
>
>> But it
>> only refers to them as "examples",
>
>
> I searched the word "example" and do not see where the document says that
> they
> are examples. It says that "Since different applications may use different
> cost metrics,
> the ALTO base protocol introduces an ALTO Cost Metric Registry (Section
> 14.2 of
> [RFC7285]), as a systematic mechanism to allow different metrics to be
> specified. For
> example, a delay-sensitive application may want to use latency-related
> metrics, and
> a bandwidth-sensitive application may want to use bandwidth-related
> metrics."
>
> Does this paragraph give an impression that the metrics are only examples?
> If so,
> do you suggest removing the "For example" phrase to reduce the impression?
>
> The document does have the sentence " The "Origin Example" column of Table
> 1 gives an example RFC that has defined each metric." Here the word
> "example"
> word means one existing work.
>
>
>> without actually defining how exactly they
>> are to be used with ALTO, or - if not those - which actual metrics are
>> supposed
>> to be used.
>>
>
> The document has "... the ALTO base protocol introduces an ALTO Cost
> Metric Registry
> (Section 14.2 of [RFC7285]), as a systematic mechanism to allow different
> metrics
>  to be specified. " and "When an ALTO server supports a cost metric
> defined in this document,
> it should announce this metric in its information resource directory (IRD)
> as defined in
>  Section 9.2 of [RFC7285]." Does this provide enough on how exactly they
> should be used?
> The function of this document is to satisfy the registry and the use will
> be in the base protocol
> (RFC7285). If there is a specific suggestion, it will be good to have.
>
>
>> Defining a mechanism for exposing metric information to clients isn't
>> really
>> useful unless the content of that information is much more clearly
>> specified.
>>
>> I agree with this statement that information should be specified as
> clearly as
> possible, but at the same time, we need abstraction to reduce the
> complexity.
> One guiding principle in the design is that ALTO information provides
> reasonable guidance, not mathematical precision.
>
>
>> Section 4.1.3. , paragraph 2, discuss:
>> >Intended Semantics: To give the throughput of a TCP congestion-
>> >control conformin

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

[Y. Richard Yang]

tion
> (apart fr
> >   
> The usual collocation for "independent" is "of", not "from". Did you mean
> "independent of"?
>
> Section 3.4.3. , paragraph 6, nit:
> > imation" method. See Section 3.1.4 on on related discussions such as
> summing
> >^
> Possible typo: you repeated a word.
>
> Section 3.5.4. , paragraph 3, nit:
> >  [RFC8312]), it helps to specify as much details as possible on the the
> cong
> > 
> Use "many" with countable plural nouns like "details".
>
> Section 3.5.4. , paragraph 3, nit:
> > ify as much details as possible on the the congestion control algorithm
> used
> >^^^
> Two determiners in a row. Choose either "the" or "the".
>
> These URLs in the document can probably be converted to HTTPS:
>  *
> http://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#cost-metrics
>
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] CERN?

[Y. Richard Yang]

Hi Martin,

The ALTO team had a collaboration with CalTech/CERN team in early days,
with main contacts at the time being Prof. Harvey Newman (CalTech
new...@hep.caltech.edu), Justas Balcas (CERN/CalTech, justas.bal...@cern.ch),
and Dorian Kcira (dorian.kc...@cern.ch). Jensen, Kai and Qiao were
involved in some testbed. Let us collect the info and send it to you soon.

Thanks!
Richard

On Wed, Nov 17, 2021 at 10:56 AM Martin Duke 
wrote:

> I've read that ALTO is used for some large data transfers at CERN. Does
> anyone have a contact there that can talk about this? We're trying to do
> some promotional material for IETF, and it would be a good testimonial.
>
> Thanks,
> Martin
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =============
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Artart last call review of draft-ietf-alto-performance-metrics-17

[Y. Richard Yang]

Hi Christian,

We made two changes to address your comments. Please see below.

>
> > > * Allowing decimals into the cost metric identifier introduces a dot
> which
> > >   is reserved as per RFC7285 Section 10.6.
> >
> > Yes. Correct. From the grammar above, we made sure that we would not
> > introduce a dot. We can add a sentence to point out that when choosing
> the
> > base, we should follow this. Should we do this?
>
> I think it'd be easiest (with the grammar or without) to to introduce
> the number as a nonnegative integer. (That'd allow dropping mentions of
> the minus and exp components).
>

The idea of making the number following p as a non-negative integer 0..100
is quite interesting.
If we limit the precision to only 2 digits, we are all set. One issue is
that we may need higher
precision such as 99.9%. One possibility then is to consider delay-rt:p
as the 0.
quantile. For example, delay-rt:p999 is the 99.9%, delay-rt:p01 is the
0.1%. One issue of
this design, however, is that we cannot represent 100% precisely.

As a result, this is the current version to address your comments:

NEW:

percentile, with letter 'p' followed by a number:

  gives the percentile specified by the number following the letter
  'p'.  The number MUST be a non-negative JSON integer in the range
  [0, 100] (i.e., greater than or equal to 0 and less than or equal
  to 100), followed by an optional decimal part, if a higher precision
  is needed.  The decimal part should start with the '.' separator
  (U+002E), and followed by a sequence of one or more ASCII numbers
  between '0' and '9'.  The total length of the cost metric string
  MUST not exceed 32, as required by [RFC7285].  Assume this number
  is y and consider the samples coming from a random variable X.
  Then the metric returns x, such that the probability of X is less
  than or equal to x, i.e., Prob(X <= x), = y/100.  For example,
  delay-ow:p99 gives the 99% percentile of observed one-way delay;
  delay-ow:p99.9 gives the 99.9% percentile.  Note that some systems
  use quantile, which is in the range [0, 1].  When there is a more
  common form for a given percentile, it is RECOMMENDED that the
  common form being used; that is, instead of p0, use min; instead
  of p50, use median; instead of p100, use max.


> > >   A few words on which statistic can be used with which metric could
> > >   also help with bw-maxres. (What does bw-maxres-p50 mean, is it
> > >   meaningful at all?)
> >
> > Mathematically, any percentile of a set of a single value is the value
> > itself. But it is indeed a good idea to clarify it. We will add a
> sentence
> > at the end of 2.2
> >
> > => Note that although one can use generic statistics (i.e., any
> percentile
> > in [0, 100]) and multiple specifications may give the same value, it
> helps
> > to choose the more intuitive and robust definition. For example, when the
> > set is expected to be a single value. The max operator is more robust and
> > hence recommended.
>
> That sounds more confusing to me (the max operator ... so I should use
> bw-maxres-max?); maybe (if correct) something like
>
> | Note that unlike the other metrics, maxres is a single value and not
> | sampled over time. Thus, it MUST NOT be specialized with a stat
> | indicator, but is to be used in the base form.
>
>
After some thinking, we think the best way to address your comments is to
introduce
a new statistical operator, and this is a nice fix. Specifically, here is
the proposal:

NEW:

2.2.  Performance Metric Statistics

   The measurement of a performance metric often yields a set of samples
   from an observation distribution ([Prometheus]), instead of a single
   value.  A statistical operator is applied to the samples to obtain a
   value to be reported to the client.  Multiple statistical operators
   (e.g., min, median, max) are being used.

   Hence, this document extends the general US-ASCII alphanumeric cost
   metric strings, formally specified as the CostMetric type (defined in
   Section 10.6 of [RFC7285]; see above in the CostType definition), as
   follows:

  A cost metric string consists of a base metric identifier (or base
  identifier for short) string, followed by an optional statistical
  operator string, connected by the ASCII character colon (':',
  U+003A), if the statistical operator string exists.

   Examples of cost metric strings then include "delay-ow", "delay-
   ow:min", "delay-ow:p99", where "delay-ow" is the base metric
   identifier string; "min" and "p99" are example statistical operator
   strings.

   The statistical operator string MUST be one of the following:

   cur:

  the instantaneous observation value of the metric from the most
  recent sample (i.e., the current value).

   percentile, with letter 'p' followed by a number:

   ...

  If a cost metric string does not have the optional statical operator
   string, the 

Re: [alto] Artart last call review of draft-ietf-alto-performance-metrics-17

[Y. Richard Yang]

Hi Christian,

On Tue, Oct 19, 2021 at 2:54 AM Christian Amsüss 
wrote:

> Hello Richard,
>
> On Mon, Oct 18, 2021 at 03:43:50PM -0400, Y. Richard Yang wrote:
> > Good comment. The document gives the high-level grammar (1 line) at the
> > beginning of Sec. 2.2.
> > It looks that your suggestion is the write out the complete grammar
> upfront:
>
> I was not so much looking for the details of the terms "where 
> MUST be one of the following" was fine) but for
>
> a) naming the formal language this is in. Reading, I've guessed that the
>   square brackets mean "optional" because I've seen that in DOS-time
>   documentation, and it looks formal, but does not declare a language.


>
  A formal language that could be used here and is common in RFCs would
>   be ABNF.
>
>
I see. See below, as we can address them together.


> b) the tying in of the output -- the the term "metric-identifier" is not
>   used anywhere else, and RFC7285 uses a CostMetric type in the
>   cost-metric field; I'd appreciate if these identifiers were somehow
>   linked.
>
  This would be trivial had ALTO used CDDL to describe its JSON, as
>   then there could be a line like `cost-metric //= metric-identifier`;
>   maybe the `object { ... }` notation has something similar?
>
> The object notation is higher granularity and hence cannot handle strings
structure.


>   RFC7285 generally does without constructing string identifier, so
>   there is no ABNF in there.
>
> Correct.


>   If you go with the suggested colon structuring and have text for that,
>   possibly there the optionality and string concatenation be described
>   in ABNF (or just in words with an example), and the need for a formal
>   language would go away here.
>
>
Good comment. How about the following:

Old Sec. 2.2
"Hence, each performance metric's identifier
   should indicate the statistic (i.e., an aggregation operation), to
   become
::=  [ '-'  ]
   where  MUST be one of the following:
 "

=>

"Hence, this document extends the general US-ASCII alphanumeric cost metric
strings (formally specified as the CostMetric type in Section 10.6 of
[RFC7285]) as follows: A cost metric string (denoted )
consists of a base metric identifier string (denoted
) followed by an optional statistics string
(denoted ), connected by the ASCII character colon (':', U+003A), if
the statistics field exists. Examples of cost metric strings include
"delay-ow", "delay-ow:min", "delay-ow:p99".

> "...  Note that some systems use quantile, which is in the range [0, 1].
> > This document uses percentile to make the identifier easier to read. When
> > there is a more common form for a given percentile, it is RECOMMENDED
> that
> > the common form being used; that is, instead of p0, use min; instead of
> > p50, use median; instead of p100, use max".
>
> Fine with me.
>
>
Great.


> > > * Allowing decimals into the cost metric identifier introduces a dot
> which
> > >   is reserved as per RFC7285 Section 10.6.
> >
> > Yes. Correct. From the grammar above, we made sure that we would not
> > introduce a dot. We can add a sentence to point out that when choosing
> the
> > base, we should follow this. Should we do this?
>
> I think it'd be easiest (with the grammar or without) to to introduce
> the number as a nonnegative integer. (That'd allow dropping mentions of
> the minus and exp components).
>
> Agree.


> > >   A way out could be to formalize this structure and register the
> > >   metric-base-identifiers for use with and without a stat parameter
> > >   following the colon (instead of the dash).
> >
> > So the suggestion is that ":" as the consistent internal structure
> > separator. This is quite reasonable.
>
> Just beware that this is formally an update to the registry; not sure
> whether that incurs an "updates" to 7285.
>
>
No. This will not update 7285. Sec. 10.6 of RFC7285 requires registration
and we will do so.



> > >   A few words on which statistic can be used with which metric could
> > >   also help with bw-maxres. (What does bw-maxres-p50 mean, is it
> > >   meaningful at all?)
> >
> > Mathematically, any percentile of a set of a single value is the value
> > itself. But it is indeed a good idea to clarify it. We will add a
> sentence
> > at the end of 2.2
> >
> > => Note that although one can use generic statistics (i.e., any
> percentile
> > in [0, 100]) and multiple specifications may give the same value, it
> helps
> > to choose the more intuitive and robust definition. For examp

Re: [alto] Meeting Info for Oct 19, 2021

[Y. Richard Yang]

Dear all,

It looks that we have some confusion or we have scheduled two
meetings, first 9-10 (this one), and then 10-11 (G2).

Richard

On Mon, Oct 18, 2021 at 9:49 PM  wrote:

> Dear all,
>
>
> This is a friendly reminder that we will have the weekly ALTO meeting* on
> 9:00 am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, October
> 19, 2021*.
>
>
> *Agenda:*
>
>
> - Updates for the WG drafts
>
> - Discussion on IETF 112 topics
> Bridge:
>
> https://yale.zoom.us/my/yryang
>
>
> If anyone has other topics to be discussed, please feel free to let me
> know.
>
>
> Best,
>
> Kai
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [art] Artart last call review of draft-ietf-alto-performance-metrics-17

[Y. Richard Yang]

Hi Christian,

Thanks for the update. Can you please take a look at the responses to your
review in the previous email to see if they are addressing the two issues
below?

Richard

On Mon, Oct 18, 2021 at 10:14 AM Christian Amsüss 
wrote:

> Hello,
>
> On Mon, Oct 18, 2021 at 07:02:08AM -0700, Christian Amsüss via Datatracker
> wrote:
> > ## Summary for the IoT Directorate
>
> I performed the review with the wrong hat on, sorry for the mixup.
>
>
> Refocusing on the ART review criteria brings up nothing new -- but the
> point about the formal language used with metric-identifier deserves
> more emphasis.
>
> Likewise, the point about registration of the stat-typed metric
> identifiers (and the possible structuring of the registry into
> registered prefixes and per-prefix semantics for what is behind a colon)
> now falls more directly into the scope of the review.
>
> Otherwise, what was said with focus on the IoT applies likewise to the
> use of HTTP and other general ART topics:
>
> > As for conventions around the Internet of Things, this makes no choices
> -- if
> > follows the path set out by ALTO, and adds terms and considerations for
> metrics
> > established outside of ALTO.
>
> Best regards
> Christian
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Artart last call review of draft-ietf-alto-performance-metrics-17

[Y. Richard Yang]

Hi Christian,

Thank you so much for the review. Please see below.

On Mon, Oct 18, 2021 at 10:02 AM Christian Amsüss via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Christian Amsüss
> Review result: Ready with Issues
>
> ## Summary for the IoT Directorate
>
> This document extends the Application-Layer Traffic Optimization (ALTO)
> protocol, by which applications that need to a peer from a selection can
> ask
> their uplink for preferences. It adds more fine-grained vocabulary to pick
> the
> peer with best expected bandwidth, or best latency.
>
> As for conventions around the Internet of Things, this makes no choices --
> if
> follows the path set out by ALTO, and adds terms and considerations for
> metrics
> established outside of ALTO.
>
> The mechanisms (more of ALTO than this particular document) can be
> applicable
> to IoT applications when unconstrained devices relay data into cloud
> systems --
> then they might make better choices in presence of decentralized backends.
> If
> this document gains traction in deployments, these systems will need deeper
> application knowledge pertaining to the application's requirements
> (selecting
> the low-latency vs. the high-bandwidth option).
>
> ## High-level
>
> The document can be followed well after brief familiarization with ALTO;
> it is
> in a good over-all shape.
>
> 2.2 Performance Metric Statistics:
>
> * The metric-identifier definition seems disconnected with the rest of the
>   terminology. I assume from context that this is a way for building a
>   CostMetric value. If this assumption is wrong, some of the later points
> are
>   moot.
>
>   (By the way, what language is the metric-identifier definition?  It's not
>   ABNF, and I don't find any other formal language in thenormative
> references.)
>
> Good comment. The document gives the high-level grammar (1 line) at the
beginning of Sec. 2.2.
It looks that your suggestion is the write out the complete grammar upfront:

 ::=  [ '-'  ]


=>


 ::=  [ '-'  ]


 ::= `delay-ow` | `delay-rt` | `delay-variation`
   | `hop-count` | `lossrate` | `tput`

   | `bw-residual` | `bw-maxres`

 ::= `min` | `max` | `median` | `mean` | `stddev` | `stdvar`
 | `p`

 := ASICC number between 0 and 100, inclusive.


Is the above what you have in mind?



> * p0 and p100 are aliases to min and max IIUC. Is there a preferred form,
> and
>   why is the other form allowed? (Same for p50 and median.)
>
> p is a uniform notation. Singling out 0, 50, 100 creates
complexity, although there is the more common
min/max/median. How about we add a sentence at the end of the paragraph:

"...  Note that some systems use quantile, which is in the range [0, 1].
This document uses percentile to make the identifier easier to read."
=>
"...  Note that some systems use quantile, which is in the range [0, 1].
This document uses percentile to make the identifier easier to read. When
there is a more common form for a given percentile, it is RECOMMENDED that
the common form being used; that is, instead of p0, use min; instead of
p50, use median; instead of p100, use max".


> * Allowing decimals into the cost metric identifier introduces a dot which
> is
>   reserved as per RFC7285 Section 10.6.
>
>
Yes. Correct. From the grammar above, we made sure that we would not
introduce a dot. We can add a sentence to point out that when choosing the
base, we should follow this. Should we do this?



> * comparing to 7 IANA Considerations: The registered identifeirs are only
> the
>   metric-base-identifiers.
>
>   Registering all combined values from metric-base-identifier x stat is not
>   practical (especially with the numeric percentiles); however, the 'priv:'
>   prefix indicates that some structure was intended in RFC7285.
>
>   A way out could be to formalize this structure and register the
>   metric-base-identifiers for use with and without a stat parameter
> following
>   the colon (instead of the dash).
>

So the suggestion is that ":" as the consistent internal structure
separator. This is quite reasonable.


> * Section 2.2 (Performance Metric Statistics) allows adding -stdvar to
>   metric-base-identifiers; delay-variation-mean is probably similar to
>   delay-ow-stdvar. It's only similar (and not identical) due to the offset
> from
>   minimum detailed in 3.3.3; anyhow, pointing out that out in the "Note
> that in
>   statistics" paragraph, e.g. as in "... networking convention. Due to
> this, it
>   is expressed as a dedicated metric and not just as delay-ow-stddev".
>
>
OK. Sounds good. We will add the note.


>   A few words on which statistic can be used with which metric could also
> help
>   with bw-maxres. (What does bw-maxres-p50 mean, is it meaningful at all?)
>
>
Mathematically, any percentile of a set of a single value is the value
itself. But it is indeed a good idea to clarify it. We will add a sentence
at the end of 2.2

=> Note that although one 

[alto] ALTO Oct. 19 Weekly Meeting on G2 (Note a different time: 10:00 AM ET instead of 9 AM)

[Y. Richard Yang]

Dear ALTOers,

The weekly meeting tomorrow Oct. 19, 2021 is one hour later than the
traditional time. The goal of the meeting is to discuss collaboration
between ALTO and G2.

Time: Oct. 19 from 10-11 AM US ET
Format: Hybrid (G2 team + Richard) at Yale campus + Zoom (
https://yale.zoom.us/my/yryang)
Agenda:
- Brief introduction
- Dr. Kai Gao (ALTO -> G2; G2 -> ALTO)
- Open discussions

G2 related readings:
- On the bottleneck structure of congestion-controlled networks
;
- Designing data center networks using bottleneck structures
;
- Computing bottleneck structures at scale
;
- Quantitative theory of bottleneck structures for data networks

; Online demo 

ALTO related reading:
- ALTO base protocol: https://datatracker.ietf.org/doc/html/rfc7285
- Flow director:
https://people.csail.mit.edu/gsmaragd/publications/CoNEXT2019/
- ALTO path vector protocol:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector
- ALTO unified property:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-18
- ALTO theory foundation: https://dl.acm.org/doi/abs/10.1145/1402946.1402999
- Reactive bw prediction: https://ieeexplore.ieee.org/document/8486372
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Oct 5, 2021

[Y. Richard Yang]

Hi Danny,

Thanks for the kind note. It is always wonderful to work with you!

Richard

On Mon, Oct 4, 2021 at 11:21 AM Danny Lachos  wrote:

> Hello ALTOers,
>
> Finally, I am in Berlin
>
> Now here at Benocs, I will continue to participate in the WG discussions &
> weekly meetings
>
>
> Talk to you tomorrow
>
>
> On 04.10.21 16:26, kai...@scu.edu.cn wrote:
>
> Dear all,
>
>
> This is a friendly reminder that we will have our ALTO weekly meeting* at
> 9:00 am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, October
> 5, 2021.*
>
>
> *Reminder:*
>
> We will have 3 weekly meetings before the draft submission deadline (Oct
> 25) and 5-6 weekly meetings before IETF 112 (Nov 6-12).
>
>
> *Agenda:*
>
> - Planning of weekly meetings before IETF 112
>
> - Trial editorial session for path vector
>
>
> *Bridge:*
>
> https://yale.zoom.us/my/yryang
>
>
> Best,
>
> Kai
>
> ___
> alto mailing listalto@ietf.orghttps://www.ietf.org/mailman/listinfo/alto
>
> _______
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] charter-ietf-alto-04-01

[Y. Richard Yang]

Hi Lars,

I saw your comment and have to chime in.

I have to respectfully disagree with your assessment: "Overall, I remain
unconvinced that there is sufficient work/interest in this space to warrant
a chartered WG." I am not sure if you attended the NAI@SIGCOMM'21 Workshop
yesterday. There was clearly a huge interest and work in the space. The
title of Amin Vahdat's talk is "Application-Defined Networking", as "It now
opens the next wave of opportunities toward Application-Defined Networking,
Where application efficiency metrics drive network control configuration
policy, Integration into compute and storage infrastructure→ job placement,
replication, Visibility into distributed systems structure, including Load
Balancing, Thread Scheduling, RPCs, RDMA, and Collectives", using the
sentences from the keynote. Now, let's go more specific to ALTO and to
engineering. The work of Flow Director, in the scope of ALTO, was reported
in CoNEXT'19 (https://gsmaragd.github.io/publications/CoNEXT2019/). Luis
mentioned ongoing deployment efforts at Telefonica; there is the on-going
deployment of ALTO at the Greater Bay Network, which is a large, among the
most-advanced networks covering Shenzhen, Hong Kong; there is the ongoing
MoWIE work, based on and the need to extend ALTO, by China Mobile and
Tencent...  I agree that ALTO is far far far from taking over the world,
but I have a totally different assessment.

If when you say that there is not sufficient work, you mean that *the
charter* does not include sufficient work. This is by design and good
guidance: the WG substantially limits the scope of the recharter to
consolidate the WG in the short term, and there was a huge disappointment
from many industry parties on the removing of their work from the charter
discussions---not sure if you attended some of the recharter discussions,
there was a large amount of proposed work but they were mostly removed.

Please see below.

On Tue, Aug 24, 2021 at 9:29 AM Lars Eggert  wrote:

> Hi,
>
> On 2021-8-24, at 16:07, Qin Wu  wrote:
> > Thank you for reviewing the proposed re-charter of the ALTO working
> group.
>
> > > It's not clear to me why this effort would need a chartered WG vs.
> just a
> > > mailing list and/or a wiki.
>

 A chartered WG has many benefits. As one example, multiple participants
spend huge efforts on the ALTO work and bring "human resources" to IETF; an
informal mailing list/wiki will be harder to justify the efforts. I assume
that many IETF WGs can also operate mostly as a mailing list/wiki; then the
participation can be lower, it will be harder to maintain scope, to meet
deadlines. We feel that the WG recharter has wonderful guidance to be
focused, to be timely.

>
> > >> o Develop operational support tools for ALTO.
> > >
>

See above.


> > > I'm not aware of any larger-scale product deployments of ALTO - do
> some exists?
>

See some examples above.

> > Otherwise, I question whether operational tools can effectively be
> developed
> > > without relevant operational experience.


> > There is big suggestion that the reason for no larger-scale product
> deployment of ALTO is because missing operational support tools.
> > It is big mistake to make protocol without operational support.
> > We saw this happen many times with OAM added much later. It make the
> protocol hard to use and is bad for operator.
>
> Would you point me at a discussion where this lack of operational support
> was brought up by a potential large-scale deployer as a reason to not
> deploy ALTO?
>
>
The issue of lacking operational support was not proposed by academics, but
by people from the operator sides, during ALTO meetings, e..g., by Lyle
Bertz (T-Mobile), Luis (Telefonica). The main complexity discussed by the
Steering Giants report was mostly operational.

> >> o Support for modern transport protocols. ALTO only uses the
> capabilities of
> > >> HTTP version 1. Since then, the IETF has developed HTTP/2 and HTTP/3.
> The
> > >> working group will develop any necessary protocol extensions and
> guidance to
> > >> support the use of ALTO over HTTP/2 and HTTP/3.
> > >
> > > This seems to fall under the "protocol maintenance" bullet above, so
> I'm not
> > > clear why this is a separate bullet. As stated above, this could be
> done in
> > > TSVWG if anyone cared.
> >
> > All work on a protocol after first RFC is “protocol maintenance”. We
> could write charter as single bullet “Do protocol maintenance” but that is
> not helpful to guide participants and make AD manage WG.
>
> I'll note that the charter actually does contain a bullet to "perform
> protocol maintenance", which is why I pointed out the overlap?
>
> > Also, this is big and important next step to make ALTO more relevant and
> useable in current Internet.
>
> What particular features of H2 and H3 would make ALTO more relevant and
> deployable in the current Internet? H2 or H3 do not obsolete H1.
>

SSE is an important feature; see Sec. 4.3.3 of aforementioned 

[alto] NAI@SIGCOMM'21 (Monday, Aug. 23)

[Y. Richard Yang]

Dear ALTOers,

We want to kindly invite you to attend NAI'21 tomorrow (Monday, Aug. 23) at
SIGCOMM'21, because we feel that the program is highly relevant and your
participation and engagement can be very valuable..

Some *highlights*:
- Keynote (10:10-10:50 AM EDT):
  *Title: “Dynamic Network Adaptation (DNA)”*
  Keynote Speaker: *Jonathan Smith (Olga and Alberico Pompa Professor,
UPenn/DARPA Program Manager)*

- Keynote (12:30-13:15)
  Title: *Application-Defined Networking*
  Keynote Speaker: *Amin Vahdat* (Engineering Fellow and Vice President of
Systems Infrastructure)

- Panel (15:50-16:55)
  Richard Alimi (Google)
  Yixue Lei (Tencent)
  Håkon Lonsethagen (Telenor)
  Qin Wu (Huawei)
  Zhi-Li Zhang (Univ. of Minnesota)

Panel questions:
Q1. Can you describe one key NAI, broadly defined (i.e., network-aware
applications, application-aware networking, or both), project that you are
involved in or consider to be important (which can be by others)?
Q2. In your opinion, what are the most important one or two trends and
opportunities, in either industry development or academic research, in
application-aware networking (AAN)? For each trend or opportunity, what are
the key challenges to be addressed for it to be successful?
Q3. In your opinion, what are the most important trends and opportunities,
in either industry development or academic research, in network-aware
applications (NAA)? For each trend or opportunity, what are the key
challenges to be addressed for it to be successful?
Q4. Do you see the integration of AAN and NAA, or they should/will develop
independently?

Participation details:
- Time: Monday, August 23, 2021, 15:50 pm-17:00 EDT
- *Zoom link*:
https://zoom.us/j/95681536728?pwd=N2NwNjdWRWJCZ2RrMzI3N1hvYlRYdz09
- Complete program
  https://conferences.sigcomm.org/sigcomm/2021/workshop-nai.html

We look forward to seeing many of you.

Richard

-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Fwd: I-D Action: draft-ietf-alto-performance-metrics-16.txt

[Y. Richard Yang]

Hi Martin, ALTO WG,

We have uploaded an updated version to address the wonderful AD reviews. A
good way to see all changes will be the diff:
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-16

At a high level, the main types of changes are to address the high-level
comments are:
- remove "import" so that we do not have the issues of defining the format
of referring to exact RFCs and details of estimation methods. This is
clarified at the beginning of Section 2---it used the new text of AD and
added some more text.
- clarify that the link will be opaque (either human read or machine
readable for automation). An example is Sec. 3.1.4.

We believe that we have addressed all other issues in the review.

Thank you so much!

Richard & authors


-- Forwarded message -
From: 
Date: Sun, Jul 11, 2021 at 7:19 PM
Subject: [alto] I-D Action: draft-ietf-alto-performance-metrics-16.txt
To: 
Cc: 



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   : ALTO Performance Cost Metrics
Authors : Qin Wu
          Y. Richard Yang
  Young Lee
  Dhruv Dhody
  Sabine Randriamasy
  Luis Miguel Contreras
Filename: draft-ietf-alto-performance-metrics-16.txt
Pages   : 33
Date: 2021-07-11

Abstract:
   Cost metric is a basic concept in Application-Layer Traffic
   Optimization (ALTO), and different applications may use different
   cost metrics.  Since the ALTO base protocol (RFC 7285) defines only a
   single cost metric (i.e., the generic "routingcost" metric), if an
   application wants to issue a cost map or an endpoint cost request to
   determine the resource provider that offers better delay performance,
   the base protocol does not define the cost metric to be used.

   This document addresses the issue by introducing network performance
   metrics, including network delay, jitter, packet loss rate, hop
   count, and bandwidth.

   There are multiple sources (e.g., estimation based on measurements or
   service-level agreement) to derive a performance metric.  This
   document introduces an additional "cost-context" field to the ALTO
   "cost-type" field to convey the source of a performance metric.



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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-16


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Y. Richard Yang]

Hi Martin,

Thanks for the quick feedback. Please see below.

On Mon, Apr 5, 2021 at 11:03 AM Martin Duke  wrote:

> Hi Richard,
>
> Where needed, responses inline.
>
> On Fri, Apr 2, 2021 at 6:18 PM Y. Richard Yang  wrote:
>
>> - Sec 2.1. The cost-source model is conceptually sound, but the
>>> justification for it seems underexplained. What exactly is a client going
>>> to do with this information? What different behaviors would a client
>>> execute if the context was e.g. "sla" instead of "nominal?" To the extent
>>> the parameters are not machine readable, like links to webpages, are we
>>> really expecting this information to be presented to the humans behind ALTO
>>> clients?
>>>
>>
>> Good comment. This is a point which the WG indeed discussed multiple
>> times. The decision was that providing the source will give the server the
>> ability to indicate the source, and the client knows more about the
>> context. Some operational aspects are discussed in Sec. 5.1. There were
>> some discussions on potential normative specifications on the client-side
>> and/or the server-side, but the final decision is that ALTO provides
>> non-normative information. For example, the basic cost values are
>> non-normative, and only best-effort information. There can be out-of-ALTO
>> control loops, for example, business contracts, and the cost-source
>> supports indication of such information channel.
>>
>> The comment on clarifying whether the info will be for humans behind is a
>> great one. One use case setting discussed is that the link can provide
>> machine-readable specifications such as a machine-readable language
>> specifying the measurement parameters, but this is considered out of scope.
>> Will you recommend that we include more some more elaboration in the
>> operational considerations section (i.e., extending Sec. 5.1)?
>>
>
> If it were me, I'd put some of it in the intro and some motivation in 2.1,
> and maybe go through some miscellaneous considerations in 5. But that's
> less important that it be there somewhere.
>
> Thanks for the note. We are adding a few sentences in 5.


> If the intent is that it be machine-readable, then there are several
> places where this standard is going to need more standardization (i.e.
> precise definition of text fields).
>

Some of the authors discussed the issue and feel that going down the path
of making the content machine-readable, in a systematic way, adds
substantial complexity.
.

> But zooming out: I understand that the point is that "the client knows
> more about the context," which is pretty much what 5.1 says. But I don't
> understand if the "client" is the user or a user agent, and what either one
> would actually do with the information. Would the application execute a
> policy based on the source? Why would it use a latency that came from an
> sla, but not from measurement? etc.
>

This is a good comment. Here is an example (
https://ipnetwork.bgtmo.ip.att.net/pws/averages.html) that motivated some
early discussions. In this example, AT post both target (aka sla. should
we change the name from sla to service-level-target?) and actual
measurements. In this sense, ALTO can be considered as a standard way of
providing and update the information. Both target and actual values can be
useful. Make sense?

>
>
>
>>
>>> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
>>> this refer to an SLA the ALTO client has with the network? Between the
>>> target IP and the network? Or something else? If the first, does this link
>>> to client authentication in some way? If the second, what are the privacy
>>> implications of exposing these SLAs?
>>>
>>
>> It is target IP and the network. Here is some text in the current version
>> on the authentication and privacy aspects (Sec. 6):
>> "Indeed, TE
>>performance is a highly sensitive ISP information; therefore, sharing
>>TE metric values in numerical mode requires full mutual confidence
>>between the entities managing the ALTO server and the ALTO client.
>>ALTO servers will most likely distribute numerical TE performance to
>>ALTO clients under strict and formal mutual trust agreements.  On the
>>other hand, ALTO clients must be cognizant on the risks attached to
>>such information that they would have acquired outside formal
>>conditions of mutual trust."
>>
>> Will this be OK?
>>
>
> That privacy information is alright, but exposing the details of
> third-party SLAs deserves special attention.

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Y. Richard Yang]

Hi Martin,

On Tue, Mar 30, 2021 at 2:24 PM Martin Duke  wrote:

> Sorry for the fragmented review, but there are a couple of more issues:
>
> - The authors should do a review of all lower-case occurrences of must,
> should, may, and recommended. At least a few of them should be capitalized
> to indicate normative requirements.
>

Yes. We are taking a pass and are almost done.

>
> - IMO, from a quick review,  I-D.ietf-ippm-initial-registry as written is
> normative and should be listed as such. However, I think it would be better
> to simply refer to the actual registry (
> https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml)
> rather than tie it to the initial entries.
>
> Agree that referring to the registry is a better design and we will do the
normative reference in the update.

Thanks!
Richard



> On Mon, Mar 29, 2021 at 5:30 PM Martin Duke 
> wrote:
>
>> One small correction: I'm jumping the gun on the author policy; 6 is
>> probably OK for now.
>>
>> On Mon, Mar 29, 2021 at 11:33 AM Martin Duke 
>> wrote:
>>
>>> Hello authors,
>>>
>>> Thank you very much for writing this draft. It is clearly a useful
>>> extension to ALTO and is quite clearly written, even to someone who is not
>>> a practitioner. I have numerous comments/questions and a few nits.
>>>
>>> These points are all invitations to discussion, rather than commands
>>> about what to change, as I've missed much of the WG deliberations that led
>>> to this text.
>>>
>>> COMMENTS:
>>> - There are six authors. Having more than 5 editors/authors listed on
>>> the front page requires strong justification and chair/AD approval. See the
>>> RFC Editor statement [1]. You are encouraged to designate a few editors for
>>> the front page and list as many authors as desired at the end.
>>>
>>> - Sec 2.1. The cost-source model is conceptually sound, but the
>>> justification for it seems underexplained. What exactly is a client going
>>> to do with this information? What different behaviors would a client
>>> execute if the context was e.g. "sla" instead of "nominal?" To the extent
>>> the parameters are not machine readable, like links to webpages, are we
>>> really expecting this information to be presented to the humans behind ALTO
>>> clients?
>>>
>>> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
>>> this refer to an SLA the ALTO client has with the network? Between the
>>> target IP and the network? Or something else? If the first, does this link
>>> to client authentication in some way? If the second, what are the privacy
>>> implications of exposing these SLAs?
>>>
>>> - Sec 2.1. Related to the above, the text suggests that any cost-source
>>> expressed as "import" could also be expressed as "estimation". Why would
>>> the server do this? The text should say, or perhaps it would be
>>> conceptually cleaner if "estimation" and "import" were mutually exclusive
>>> sources by definition.
>>>
>>> - Sec 3. I would prefer it if the parameters field in each of these
>>> definitions was a bit more strict. This relates to my confusion about
>>> machine-readable vs. human readable data; if this is meant to be
>>> machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
>>> out that the IGP protocols should be in a format with the RFC number, for
>>> instance. If it's to be human readable for a purpose I don't understand,
>>> then these looser definitions are probably OK.
>>>
>>> - Sec 3.4 Unlike the other metrics, I have no idea what a client is to
>>> do with the hop count metric, since clients don't care about hop count.
>>> Hops only affect users through delay and loss rate, which is present in
>>> other metrics. Is the intent here to provide a proxy for delay when direct
>>> delay information is not available? If so, we should say so.
>>>
>>> - Sec 5.3. I suggest a reword.
>>>
>>> OLD:
>>> To address this issue, the only defined "routingcost" metric can be
>>>only "estimation".
>>>
>>> NEW:
>>> To address this issue, if the "routingcost" metric contains a
>>> cost-context field, it MUST be "estimation."
>>>
>>> What should clients do if it's not "estimation?" Can they use it or
>>> reject the metric
>>> as malformed?
>>>
>>> - Sec 5.4.1: "...the ALTO server may provide the client with the
>>> validity period of the exposed metric values."
>>>
>>> Shouldn't there be a standard format for this? Or are you implying the
>>> use of cost-calendar?
>>>
>>> - Sec 5.4.2: I don't understand what this section is saying. Can the
>>> server provide new metrics not in the spec? Or is it saying that the server
>>> can take singletons about link one-way delays and compose path one-way and
>>> two-way delays, for example?
>>>
>>> NITS:
>>> - Sec 1. An initial sentence introducing ALTO at the beginning would be
>>> helpful, e.g.
>>>
>>> "ALTO [RFC 7285] provides a means for client to identify the most
>>> efficient information source when multiple copies of such information
>>> exist, by quering 

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Y. Richard Yang]

Hi Martin,

Thank you so much for the wonderful review. Please see below.

On Mon, Mar 29, 2021 at 2:35 PM Martin Duke  wrote:

> Hello authors,
>
> Thank you very much for writing this draft. It is clearly a useful
> extension to ALTO and is quite clearly written, even to someone who is not
> a practitioner. I have numerous comments/questions and a few nits.
>
> These points are all invitations to discussion, rather than commands about
> what to change, as I've missed much of the WG deliberations that led to
> this text.
>
> COMMENTS:
> - There are six authors. Having more than 5 editors/authors listed on the
> front page requires strong justification and chair/AD approval. See the RFC
> Editor statement [1]. You are encouraged to designate a few editors for the
> front page and list as many authors as desired at the end.
>
>
I saw in the next email that this could be OK. Thanks for the follow-up
note.


> - Sec 2.1. The cost-source model is conceptually sound, but the
> justification for it seems underexplained. What exactly is a client going
> to do with this information? What different behaviors would a client
> execute if the context was e.g. "sla" instead of "nominal?" To the extent
> the parameters are not machine readable, like links to webpages, are we
> really expecting this information to be presented to the humans behind ALTO
> clients?
>

Good comment. This is a point which the WG indeed discussed multiple times.
The decision was that providing the source will give the server the ability
to indicate the source, and the client knows more about the context. Some
operational aspects are discussed in Sec. 5.1. There were some discussions
on potential normative specifications on the client-side and/or the
server-side, but the final decision is that ALTO provides non-normative
information. For example, the basic cost values are non-normative, and only
best-effort information. There can be out-of-ALTO control loops, for
example, business contracts, and the cost-source supports indication of
such information channel.

The comment on clarifying whether the info will be for humans behind is a
great one. One use case setting discussed is that the link can provide
machine-readable specifications such as a machine-readable language
specifying the measurement parameters, but this is considered out of scope.
Will you recommend that we include more some more elaboration in the
operational considerations section (i.e., extending Sec. 5.1)?


>
> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
> this refer to an SLA the ALTO client has with the network? Between the
> target IP and the network? Or something else? If the first, does this link
> to client authentication in some way? If the second, what are the privacy
> implications of exposing these SLAs?
>

It is target IP and the network. Here is some text in the current version
on the authentication and privacy aspects (Sec. 6):
"Indeed, TE
   performance is a highly sensitive ISP information; therefore, sharing
   TE metric values in numerical mode requires full mutual confidence
   between the entities managing the ALTO server and the ALTO client.
   ALTO servers will most likely distribute numerical TE performance to
   ALTO clients under strict and formal mutual trust agreements.  On the
   other hand, ALTO clients must be cognizant on the risks attached to
   such information that they would have acquired outside formal
   conditions of mutual trust."

Will this be OK?

- Sec 2.1. Related to the above, the text suggests that any cost-source
> expressed as "import" could also be expressed as "estimation". Why would
> the server do this? The text should say, or perhaps it would be
> conceptually cleaner if "estimation" and "import" were mutually exclusive
> sources by definition.
>

In the early WG discussion, they were considered separate, and then the
agreement was that import is a special case of estimation, with more
specific dependency tracking. Consider data provenance of how the ALTO data
are computed. Estimation means that the server does not want to indicate
the specific details, and the important gives a precise indication of the
exact protocols.


> - Sec 3. I would prefer it if the parameters field in each of these
> definitions was a bit more strict. This relates to my confusion about
> machine-readable vs. human readable data; if this is meant to be
> machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
> out that the IGP protocols should be in a format with the RFC number, for
> instance. If it's to be human readable for a purpose I don't understand,
> then these looser definitions are probably OK.
>
>
This is a very good comment as well! One possibility discussed was
following (the format such as those specified in
https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-24#section-7.1.2)
using a format such as RFCsecY, but such very specific specification
will cause moving dependency. 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

[Y. Richard Yang]

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look
at the design in a slightly abstract, general framework. In particular, the
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small,
fast-changing data;
- Vs: Another set of records that are stable and indexed by the
ephemeral variables; Vs can be large, but stable data.

There are two channels from the network to the application:
- Channel 1 for Ve
- Channel 2 for Vs

This definitely is a generic framework supported by some existing use cases
including what you presented.

In the general framework, Channel 1 can be ALTO or protocol specific. Since
it is short and needs low latency, it is more likely to be protocol
specific and embedded in some other protocol such as even data path
protocols (5G, ECN bits in IP); channel 2 is ALTO.

A couple of points to be considered when conducting further design:
- One thing we learned from SSE is the consistency between these two
channels (or more, as Ve can be carried by multiple channels, etc), and
- Document additional use cases beyond the demonstrated use cases.

Looking forward to talking to you (virtually) f2f tomorrow.

Richard

On Thu, Mar 11, 2021 at 5:01 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Qin,
>
>
>
> Please see inline,
>
> Thanks
>
> Sabine
>
>
>
> *From:* Qin Wu 
> *Sent:* Thursday, March 11, 2021 9:32 AM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>; IETF ALTO 
> *Cc:* alto-cha...@ietf.org; alto-...@ietf.org
> *Subject:* RE: ALTO Draft ReCharter WG review - extensible set of policy
> attributes
>
>
>
> Hi, Sabine:
>
> *发件人**:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) [
> mailto:sabine.randriam...@nokia-bell-labs.com
> ]
> *发送时间**:* 2021年3月11日 1:55
> *收件人**:* Qin Wu ; IETF ALTO 
> *抄送**:* alto-cha...@ietf.org; alto-...@ietf.org
> *主题**:* RE: ALTO Draft ReCharter WG review - extensible set of policy
> attributes
>
>
>
> Hello ALTO WG,
>
>
>
> Regarding the proposed work item on “Protocol extensions to support a
> richer and extensible set of policy attributes in ALTO information update
> request and response” (GPE for short) , I would like to add the following:
>
>
>
> This work item can be useful, among others, to allow a UE getting cellular
> network KPIs from an ALTO Server, to figure out for example whether the
> cell is congested, or which cell to choose.
>
>
>
> An ALTO Server cannot provide real-time information. With the proposed
> extensions, it can indicate a number of real-time network parameters
> against which ALTO cost values can be modulated.
>
>
>
> [Qin]: Yes, the current ALTO server can only provide non-real time or near
> real time information, performance metrics work allows ALTO server expose
> performance data. If ALTO protocol is extended to support pub sub mechanism,
>
> Providing real time information will not be an issue.
>
>
>
> But I agree in many cases, providing real time information is not
> necessary, e.g., cloud gaming use case provided Tencent and china mobile,
> their case is different from your proposed case, they will use cloud gaming
> server as ALTO client to get needed information.
>
> *[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially
> integrated with a cloud gaming server (CGS for short) . In that case, the
> ALTO information provided by the ALTO Server (AOS for short) can be made
> aware of given specific parameters captured by the CGS at a different pace.
> This may speed up the process as well.  *
>
>
>
> These parameters are received by UEs directly from the network and not
> from ALTO. The UE receives an array of ALTO cell KPI values that each
> depend on the value of a parameter. The UE can pick the  ALTO value
> corresponding to the value of the real-time parameter received from the
> network. Thus, the UE modulates the received ALTO values in real-time.
>
>
>
> [Qin]: your case is UE centric solution, UE gets network KPI from ALTO
> server and get real time parameter from another data source in the Network,
> what is not clear is how real time parameter is correlated with Network KPI
> information within UE.
>
> Also the interface between UE and RAN is not in the scope of ALTO work, I
> think.
>
> *[ [SR] ] definitely, the scope of the extension restricts to exchanges
> between AOS and AOC. The UE may have some agent that gathers and relates
> the RAN indicators and the ALTO information and passes the relevant costs
> to the application client. Again this agent is out of scope of ALTO. *
>
>
>
> This use-case is illustrated in the slides presented at the previous IETF
> 109 ALTO WG meeting, see (1), slide 4. A preliminary design with example
> IRD and ALTO request and response can be found in slides 7 and 8.
>
>
>
> Any feedback is more than welcome,
>
> (1)
> 

Re: [alto] qoRE: Pub/sub thread; Was Re: ALTO Draft ReCharter WG review(Internet mail)

[Y. Richard Yang]

udy this Quick QoS Change standards in Release 18.
>

Thank you for clarifying these two different use cases.

My first reaction is that regardless of which use case, they are good use
cases supporting the ALTO mission: network providing information that the
clients may not easily get by themselves. The wireless channels are
complex, expensive, shared channels. It is a location where the network
(ALTO) server can provide highly valuable information, but the client may
not obtain it easily (due to more limited state access, limited computation
power, the latency involved, ...)

Now back to your two use cases, I see that they can be supported using a
single mechanism (i.e., language grammar). A network may provide one or the
other, and the WG defines the grammar. Is this acceptable?

Richard


> BRs,
>
> Chunshan Xiong
>
>
>
> *From:* alto  *On Behalf Of *Y. Richard Yang
> *Sent:* Wednesday, March 10, 2021 12:13 PM
> *To:* Li Gang 
> *Cc:* alto-cha...@ietf.org; alto-...@ietf.org; Kai Gao ;
> Qin Wu ; IETF ALTO 
> *Subject:* [alto] Pub/sub thread; Was Re: ALTO Draft ReCharter WG
> review(Internet mail)
>
>
>
> Dear all,
>
>
>
> I renamed the generic email Subject line so that we may focus this thread
> on item 2.
>
>
>
> Here are two quick comments related with this thread, and I will go to
> more details as soon as I can.
>
>
>
> 1. ALTO SSE appears to be a quite useful service and it helps to adapt it
> to use more modern transport such as HTTP/2, quic.
>
>
>
> We may consider this under the sub/pub umbrella by considering the service
> as a special sub/pub:
> ALTO client can manage its subscription of network info to be pushed to
> it, where the granularity of subscription is individual ALTO resource
> query; in this model, the granularity can be quite fine-grained, depending
> on the query granularity. Hence, if we want fine-grained subscriptions, we
> can introduce these queries and leave the push/incremental encoding
> mechanism/framework alone.
>
>
>
> 2. Can we clarify more on the sub/pub use cases? A typical use case of a
> sub/pub system C is to facilitate the communication of other entities such
> as A and B. Hence, if the ALTO server is C, then who are the A and B? I can
> think of use cases where clients, for example, in a mobility/weakly
> connected setting, are A and B. Or the use case is about developing C, and
> the A and B are ALTO client/server. It helps to clarify.
>
>
>
> Richard
>
>
>
> On Sun, Mar 7, 2021 at 10:42 PM Li Gang  wrote:
>
> Hi, Qin,
>
> Please see my reply inline.
>
>
>
> Li Gang
>
>
>
> *From:* Qin Wu [mailto:bill...@huawei.com]
> *Sent:* Monday, March 8, 2021 10:52 AM
> *To:* Li Gang; kai...@scu.edu.cn
> *Cc:* alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO'
> *Subject:* RE: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi, Gang:
>
> Thanks for sharing your use case, let me rephrase what you envision for
> your use case,
>
> You want to express QoS requirement in the subscription request, the
> network exposes the network information via notification in response to
> subscription request,
>
> application operators can tune adaptive rate to improve user QoE based on
> the network information change.
>
>
>
> [Gang]: yes
>
>
>
> Can you clarify a little bit about specific application traffic patterns?
>
>
>
> [Gang]: let me take video streaming as an example, normally the downlink
> streaming content would be segmented into pieces for `10 seconds. For each
> piece, multiple video encoding rates, for example 1080p, 720p …, can be
> provided and adjusted by server. For each encoding rate, the QoS
> requirement (e.g. throughput, latency) is different. The network can
> provide such information change  (e.g. whether QoS requirement for 1080p,
> 720p is fulfilled or not) via pub/sub, which help application operator tune
> encoding rate.
>
>
>
> Secondly, I agree fine granularity pub sub can consider one time
> subscription and configure wait time as subscription policy to alleviate
> the signaling load on the network.
>
>
>
> -Qin
>
> *发件人:* Li Gang [mailto:ligan...@chinamobile.com]
> *发送时间:* 2021年3月7日 16:30
> *收件人:* kai...@scu.edu.cn; Qin Wu 
> *抄送:* alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 
> *主题:* RE: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi, Kai and Qin,
>
>
>
> Thanks for triggering the discussion on  the 2nd item of the recharter
> text.
>
> I agree that it would be better to define a generic pub/sub framework
> irrespective of specific transport protocol.
>
> We can start with a simple pub/sub mechanism, which is driven by conc

Re: [alto] Bringing operation automation cases to the list

[Y. Richard Yang]

Hi Luis,

Good summary. Please see below.

On Wed, Mar 10, 2021 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi all,
>
>
>
> Apologies for the time taking to post the operation automation cases to
> the list.
>
>
>
> As part of the re-charter discussion, four use cases will be considered
> for supporting the proposal in which respect to ALTO extensions for
> operation automation.
>
>
>
> Case 1. Extensions to RFC 7971 leveraging on previous protocol extensions
> (e.g., cost calendar, path vector) that can make necessary new
> architectural and deployment considerations
>

RFC7971 is valuable and hence an update to include the effects of protocol
extensions is highly valuable. I understand that cost calendar and path
vector are examples, and other extensions such as SSE can be included and
we want to make sure to do a relatively comprehensive update.


> Case 2. Usage of ALTO for combined compute and network selection (e.g.,
> for optimal edge computing service placement).
>

Does Case 2 belong to general protocol extension or operation automation?


>
>
> Case 3. Extensions to ALTO for acting as aggregator of information from
> different sources (e.g., TEDB, LSP DB, etc)
>

Case 3 is definitely a good use case supporting operation automation.


> Case 4. Overlay / underlay integration supported by ALTO (e.g., CDN).
>
>
>

Overlay/underlay integration can have many aspects. So the goal is to focus
on the operation automation aspect? One possibility is to define operation
automation broadly, including operation automation of not only ALTO but the
overall system (i.e., the integrated overlay/underlay). If this is the
case, we may want to specify the scope well.

Looking forward to a great discussion on Friday.

Richard


> Any comment, suggestion or indication is more than welcome.
>
>
>
> Thanks
>
>
>
> Luis
>
>
>
> __
>
> Luis M. Contreras
>
>
>
> Technology and Planning
>
> Transport, IP and Interconnection Networks
>
> Telefónica I+D / Global CTIO unit / Telefónica
>
>
>
> Distrito Telefónica, Edificio Sur 3, Planta 3
>
> 28050 Madrid
>
> España / Spain
>
>
>
> Skype (Lync): +34 91 312 9084
>
> Mobile: +34 680 947 650
>
> luismiguel.contrerasmuri...@telefonica.com
>
>
>
>
>
> --
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Pub/sub thread; Was Re: ALTO Draft ReCharter WG review

[Y. Richard Yang]

Dear all,

I renamed the generic email Subject line so that we may focus this thread
on item 2.

Here are two quick comments related with this thread, and I will go to more
details as soon as I can.

1. ALTO SSE appears to be a quite useful service and it helps to adapt it
to use more modern transport such as HTTP/2, quic.

We may consider this under the sub/pub umbrella by considering the service
as a special sub/pub:
ALTO client can manage its subscription of network info to be pushed to it,
where the granularity of subscription is individual ALTO resource query; in
this model, the granularity can be quite fine-grained, depending on the
query granularity. Hence, if we want fine-grained subscriptions, we can
introduce these queries and leave the push/incremental encoding
mechanism/framework alone.

2. Can we clarify more on the sub/pub use cases? A typical use case of a
sub/pub system C is to facilitate the communication of other entities such
as A and B. Hence, if the ALTO server is C, then who are the A and B? I can
think of use cases where clients, for example, in a mobility/weakly
connected setting, are A and B. Or the use case is about developing C, and
the A and B are ALTO client/server. It helps to clarify.

Richard

On Sun, Mar 7, 2021 at 10:42 PM Li Gang  wrote:

> Hi, Qin,
>
> Please see my reply inline.
>
>
>
> Li Gang
>
>
>
> *From:* Qin Wu [mailto:bill...@huawei.com]
> *Sent:* Monday, March 8, 2021 10:52 AM
> *To:* Li Gang; kai...@scu.edu.cn
> *Cc:* alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO'
> *Subject:* RE: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi, Gang:
>
> Thanks for sharing your use case, let me rephrase what you envision for
> your use case,
>
> You want to express QoS requirement in the subscription request, the
> network exposes the network information via notification in response to
> subscription request,
>
> application operators can tune adaptive rate to improve user QoE based on
> the network information change.
>
>
>
> [Gang]: yes
>
>
>
> Can you clarify a little bit about specific application traffic patterns?
>
>
>
> [Gang]: let me take video streaming as an example, normally the downlink
> streaming content would be segmented into pieces for `10 seconds. For each
> piece, multiple video encoding rates, for example 1080p, 720p …, can be
> provided and adjusted by server. For each encoding rate, the QoS
> requirement (e.g. throughput, latency) is different. The network can
> provide such information change  (e.g. whether QoS requirement for 1080p,
> 720p is fulfilled or not) via pub/sub, which help application operator tune
> encoding rate.
>
>
>
> Secondly, I agree fine granularity pub sub can consider one time
> subscription and configure wait time as subscription policy to alleviate
> the signaling load on the network.
>
>
>
> -Qin
>
> *发件人:* Li Gang [mailto:ligan...@chinamobile.com]
> *发送时间:* 2021年3月7日 16:30
> *收件人:* kai...@scu.edu.cn; Qin Wu 
> *抄送:* alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 
> *主题:* RE: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi, Kai and Qin,
>
>
>
> Thanks for triggering the discussion on  the 2nd item of the recharter
> text.
>
> I agree that it would be better to define a generic pub/sub framework
> irrespective of specific transport protocol.
>
> We can start with a simple pub/sub mechanism, which is driven by concrete
> use cases and then consider to extend as needed.
>
>
>
> Some of my thoughts are inline.
>
>
>
> Li Gang
>
>
>
> *From:* alto [mailto:alto-boun...@ietf.org ] *On
> Behalf Of *kai...@scu.edu.cn
> *Sent:* Friday, March 5, 2021 11:03 AM
> *To:* Qin Wu
> *Cc:* alto-cha...@ietf.org; alto-...@ietf.org; IETF ALTO
> *Subject:* Re: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi Qin,
>
> Thanks for the comments. A quick summary of my response is
>
> 1. "Pub/sub" means different things in different contexts and I think we
> must clarify what it means in the context of distributing ALTO information.
>
> 2. There are two ways of realizing complex "pub/sub" of ALTO information
> but I think they are fundamentally different deployment settings for one
> generic framework (whose details are, unfortunately, not thought through
> yet).
>
> Please see the details inline.
>
> Best,
>
> Kai
>
> -Original Messages-
> *From:*"Qin Wu" 
> *Sent Time:*2021-03-04 22:21:06 (Thursday)
> *To:* "kai...@scu.edu.cn" 
> *Cc:* "alto-cha...@ietf.org" , "alto-...@ietf.org" <
> alto-...@ietf.org>, "IETF ALTO" 
> *Subject:* Re: [alto] ALTO Draft ReCharter WG review
>
> Kai:
>
> *发件人:* kai...@scu.edu.cn [mailto:kai...@scu.edu.cn ]
> *发送时间:* 2021年3月3日 21:40
> *收件人:* Qin Wu 
> *抄送:* IETF ALTO ; alto-cha...@ietf.org; alto-...@ietf.org
> *主题:* Re: [alto] ALTO Draft ReCharter WG review
>
>
>
> Dear all,
>
>  Below are some comments on the 2nd item in the recharter text.
>
> As far as I know, the ALTO incremental update extension (RFC 8895) already
> provides a mechanism to enable the "pub-sub" of ALTO information, using
> Server-Sent 

Re: [alto] ALTO Draft ReCharter WG review

[Y. Richard Yang]

tleneck information to any domain,
> reducing the risk of exposing network vulnerability.
>
> In addition, we also studied how to control the routing across multiple
> domains to achieve more flexible end-to-end interdomain routing.
> Essentially, we propose a mechanism that allows networks to expose their
> available interdomain routes, just as BGP looking glasses, so that
> applications can control them. In this setting, we consider the privacy
> setting where each network's BGP export policies are private, and design
> interesting algorithms for applications to select the best policy-compliant
> routes without knowing the export policies. The following is the pointer
> for this study:
>
> [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 (
> https://ieeexplore.ieee.org/abstract/document/9155486)
>
> Above are our current efforts on extending ALTO to multi-domain settings.
> It would be great if we can know more about the industry efforts on network
> information exposure in multi-domain settings, and the privacy requirements
> of operators. This would be extremely helpful to push this extension
> forward! :-)
>
>
>
> Best
> Qiao
>
> On Tue, Mar 2, 2021 at 1:14 PM 刘鹏  wrote:
>
>> Hi Richard,
>>
>> Thank you. please see my reply inline below.
>>
>>
>> Peng Liu | 刘鹏
>> China Mobile | 移动研究院
>> mobile phone：13810146105
>> email: * liupeng...@chinamobile.com *
>>
>>
>> 发件人: Y. Richard Yang 
>> 时间: 2021/03/02(星期二)07:36
>> 收件人: 刘鹏 ;
>> 抄送人: IETF ALTO ;Qin Wu ;
>> 主题: Re: [alto] ALTO Draft ReCharter WG review
>>
>> Dear Peng,
>>
>> Thank you so much for the feedback. Please see below.
>>
>> On Fri, Feb 26, 2021 at 9:23 PM 刘鹏  wrote:
>>
>>> Hi WG,
>>>
>>>
>>> Here are some considerations of recharter:
>>>
>>> I believe that the multi domain problem is worthy of attention.
>>>
>>
>> It is good info.
>>
>>
>>> At present, operators also research in it, which may involve
>>> guaranteeing end-to-end network service in the future, such as delay,
>>> bandwidth, etc. There are some researches on cross domain deterministic
>>> network in the industry, which need some support from management and
>>> control plane.
>>>
>>
>>  Do you want to share some pointers?
>>
>> [Peng] As Qin said, it is hard to collect information across network
>> borders.
>>
>> Just taking deterministic network as an example, it is hard to applying
>> synchronization, unified forwarding strategy in multi domain, so there
>> are some works need to be done with management plane. Due to the large
>> scale and multi domains or operators, the management system may be
>> distributed.
>>
>> A potential way is to consider negotiating the forwarding time of each
>> domain in advance and carrying time stamp in the message to control the
>> forwarding path of each domain. While it needs some agreements like
>> contracts to prevent one party from tampering with and denying the
>> management content.
>>
>> Beside this, there may be others use case. I'm not sure if Alto servers
>> are willing to do those work, but it may be helpful to collect or configure
>> some key information.
>>
>> Who is the provider of Alto service is related to the deployment and
>>> cooperation mode. It may be difficult for operators to give too much
>>> detailed network information now. If the Alto service belongs to the
>>> operator, it may be used to help manage its own network. If Alto service
>>> belong to non operators, I think the issue of how to cooperate needs
>>> further discussion.
>>>
>>>
>>> It looks that you want to consider both modes: multidomains but single
>> operator (i.e., intra-cooperation) and multidomains and multiple operators.
>> Regardless, I agree that it is important for the work to clarify on the
>> privacy requirements.
>>
>> [Peng] Yes, agree.
>>
>> Richard
>>
>>
>>
>>
>>> Regards,
>>>
>>> Peng
>>>
>>> Peng Liu | 刘鹏
>>> China Mobile | 移动研究院
>>> mobile phone：13810146105
>>> email: * liupeng...@chinamobile.com *
>>>
>>>
>>> 发件人: Qin Wu 
>>> 时间: 2021/02/22(星期一)21:45
>>> 收件人: IETF ALTO ;
>>> 抄送人: alto-chairs ;alto-ads ;
>>> 主题: [alto] ALTO Draft ReCharter WG review
>>>
>>> Hi, :
>>>
>>> We have requested one hour session for ALTO WG meet

[alto] SIGCOMM'21 NAI Workshop

[Y. Richard Yang]

Dear all,

FYI: Our proposal for the second ACM SIGCOMM NAI Workshop during ACM
SIGCOMM'21 has been accepted. Please do consider submission to this highly
relevant venue.


Call for Submissions: ACM SIGCOMM NAI’21
The Second ACM SIGCOMM Workshop on Network-Application Integration/CoDesign
(NAI)

The Internet was designed and launched 50 years ago to satisfy yet
unforeseen applications, and the Internet's adaptation and scalability have
been proved remarkably successful over the years. However, the
general-purpose and best-effort model of the Internet continues to be
challenged with an ever-growing demand for more complex applications with
stricter application-specific requirements. How can we deliver 4k videos to
everybody? How can we ensure ultra-low latency for applications such as
self-driving cars and cloud gaming? How do applications adapt when the
underlying infrastructure cannot provide the services such as reliability
or security?

The Second ACM SIGCOMM Workshop on Network-Application Integration/CoDesign
(NAI) seeks to build on the success of the first workshop (
https://conferences.sigcomm.org/sigcomm/2020/workshop-nai.html) and
continue to foster discussions on this topic. We invite researchers from
academia and industry as well as engineers to explore novel ideas and
future directions of NAI.

See https://conferences.sigcomm.org/sigcomm/2021/workshop-nai.html and
submit papers and posters at https://nai21.hotcrp.com/. Please direct any
questions to the workshop chairs at sigcomm21...@gmail.com.

Submission deadline: May 17, 2021
Notification deadline: June 14, 2021
Workshop: August 23-27 (TBD), 2021
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Draft ReCharter WG review

[Y. Richard Yang]

 is
> currently specified for a single ALTO server in a single administrative
> domain, but a network may consist of
>
> multiple domains and the potential information sources may not be limited
> to a certain domain. The working group will investigate extending the ALTO
> framework to (1) specify multi-ALTO-server protocol flow and usage
> guidelines when an ALTO service involves network paths spanning multiple
> domains with multiple ALTO servers, and (2) extend or introduce ALTO
>
> services allowing east-west interfaces for multiple ALTO server
> integration and collaboration. The specifications and extensions should use
> existing services whenever possible. The specifications and extensions
> should consider realistic complexities including incremental deployment,
> dynamicity, and security issues such as access control, authorization
> (e.g., an ALTO server provides information for a network that the server
> has no authorization), and privacy protection in multi-domain settings.
>
>
>
> o The working group will update RFC 7971 to provide operational
> considerations for recent protocol extensions (e.g., cost calendar, unified
> properties, and path vector) and new extensions that the WG develops. New
> considerations will include decisions about the set of information
> resources (e.g., what metrics to use), notification of changes either in
> proactive or reactive mode (e.g., pull the backend, or trigger just-in-time
> measurements), aggregation/processing of the collected information  (e.g.,
> compute information and network information )according to the clients’
> requests, and integration with new transport mechanisms (e.g., HTTP/2 and
> HTTP/3).
>
>
>
> When the WG considers standardizing information that the ALTO server could
> provide, the following criteria are important
>
> to ensure real feasibility:
>
>
>
> - Can the ALTO server realistically provide (measure or derive) that
> information?
>
>
>
> - Is it information that the ALTO client cannot find easily some other way?
>
>
>
> - Is the distribution of the information allowed by the operator of the
> network? Does the exposure of the information introduce privacy and
> information leakage concerns?
>
>
>
> Issues related to the specific content exchanged in systems that make use
> of ALTO are excluded from the WG's scope, as is the issue of dealing with
> enforcing the legality of the content. The WG will also not propose
> standards on how congestion is signaled, remediated, or avoided.
>
>
>
> -Qin Wu (on behalf of chairs)
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-performance-metrics-15.txt

[Y. Richard Yang]

Hi ALTOers,

This is the revised version of the document, addressing comments and issues
identified by Danny, Jensen, Kai, authors and some comments from our
wonderful chairs.

One "interesting" change is
2001:db8::1:2345:6789:abcd -> 2001:db8::1234:5678
to make sure that the ipv6 range is within the range of Table 25 of RFC
6890.

Cheers,
Richard

On Thu, Feb 4, 2021 at 6:41 PM  wrote:

>
> 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   : ALTO Performance Cost Metrics
> Authors : Qin Wu
>   Y. Richard Yang
>   Young Lee
>   Dhruv Dhody
>   Sabine Randriamasy
>   Luis Miguel Contreras
> Filename: draft-ietf-alto-performance-metrics-15.txt
> Pages   : 33
> Date: 2021-02-04
>
> Abstract:
>Cost metric is a basic concept in Application-Layer Traffic
>Optimization (ALTO), and different applications may use different
>cost metrics.  Since the ALTO base protocol (RFC 7285) defines only a
>single cost metric (i.e., the generic "routingcost" metric), if an
>application wants to issue a cost map or an endpoint cost request to
>determine the resource provider that offers better delay performance,
>the base protocol does not define the cost metric to be used.
>
>This document addresses the issue by introducing network performance
>metrics, including network delay, jitter, packet loss rate, hop
>count, and bandwidth.
>
>There are multiple sources (e.g., estimation based on measurements or
>service-level agreement) to derive a performance metric.  This
>document introduces an additional "cost-context" field to the ALTO
>"cost-type" field to convey the source of a performance metric.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-alto-performance-metrics-15
>
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-15
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review for draft-ietf-alto-performance-metrics-12

[Y. Richard Yang]

Hi Jensen, Qin,

I thought a bit more on the suggestion by Jensen and agree with both of you
that it is OK. I have updated the document in -14.

Thanks a lot!
Richard

On Tue, Jan 12, 2021 at 4:37 AM Qin Wu  wrote:

> Jensen:
>
> My impression,  is an optional item in the ANBF, therefore the
> metric identifier can be used without  as suffix.
>
> I think your proposed change makes sense to me.
>
>
>
> -Qin
>
> *发件人:* Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
> *发送时间:* 2021年1月12日 15:36
> *收件人:* Qin Wu 
> *抄送:* IETF ALTO ; Y. Richard Yang ; Kai
> Gao 
> *主题:* Re: [alto] Review for draft-ietf-alto-performance-metrics-12
>
>
>
> Hi Qin,
>
>
>
> I agree with you that the constraints checking should rely on the
> implementation. I'm OK that it is not in the scope of this document.
>
>
>
> For other comments, I have checked v-13. I think most of them have been
> addressed, except for the following one.
>
>
>
> Section 2.2., paragraph 16:
>
>
>
> >If a metric has no  (and hence no - as well), the metric MUST
>
>
>
>   recommend adding " surrounding -, or using dash character instead;
>
>   if possible, giving the precise BNF grammar will be better, as I
>
>   see some metrics names also include the dash character ("-").
>
> >be considered as the 50 percentile (median).  Since this scheme is
>
> >common for all metrics defined in this document, below we only
>
> >specify the base identifier.
>
>
>
> Although I can understand this sentence, I still think it should be better
> clarified.
>
> I would suggest giving the BNF grammar at the beginning of this section,
> e.g.,
>
>
>
>... Hence, each performance metric's identifier
>
>should indicate the statistic (i.e., an aggregation operation), to
>
>become
>
>
>
>::=  [ '-'  ]
>
>
>
>where  MUST be one of the following:
>
>
>
> And changing the last paragraph of the section to:
>
>
>
>If '-'  is not present in , the metric MUST
>
>be considered as the 50 percentile (median).
>
>
>
> Thanks,
>
> Jensen
>
>
>
>
>
> On Tue, Jan 12, 2021 at 2:22 PM Qin Wu  wrote:
>
> Hi, Jensen:
>
> Speak as individual, My answer to your following question is false as
> well, even based on RFC7285, defining hopecount as float point value seem
> also weird.
>
> I think we can rely on implementation or some automation tools for
> constraints checking, but it is not scope of this document.
>
> For other comments, I think Richard have addressed in v-13. Please double
> check it. Thanks
>
>
>
> -Qin
>
> [alto] Review for draft-ietf-alto-performance-metrics-12
>
> Jensen Zhang  Tue, 13 October 2020 04:17 UTCShow
> header
> <https://mailarchive.ietf.org/arch/msg/alto/qZrkPza-vEUcIqQMR3OJfk8G-uw/>
>
> Dear ALTOers and authors of draft-ietf-alto-performance-metrics-12,
>
>
>
> Below is my review for draft-ietf-alto-performance-metrics-12.
>
>
>
> Best regards,
>
> Jensen
>
>
>
> ==
>
> General issue:
>
>
>
> The document is well written. I only have one question about the design
>
> part:
>
>
>
> the base ALTO protocol only uses the cost-mode to infer the value format,
>
> e.g., "numerical" infers the cost value MUST be a floating-point value; but
>
> this document requires different value formats for different cost-metrics,
>
> e.g., "delay-ow" requires the non-negative floating-point value, and
>
> "hopcount" requires the non-negative integer value. But based on
>
> Sec 11.3.2.3 of RFC7285, in the "constraints" field, "ALTO servers SHOULD
>
> use at least IEEE 754 double-precision floating point [IEEE.754.2008] to
>
> store the cost value". I wonder if a test constraint expression like "eq
>
> 3.1" for the cost-metric "hopcount" is valid. Should the ALTO server reject
>
> such a request? According to RFC7285, it should be valid. But according to
>
> this document, it is clearly always false.
>
>
>
> ==
>
>
>
> Nits and writing suggestions:
>
>
>
> Section 1., paragraph 5:
>
>
>
> >The purpose of this document is to ensure proper usage of the
>
> >performance metrics defined in Table 1; it does not claim novelty of
>
> >the metrics.  The Origin column of Table 1 gives the RFC which
>
> >defines each metric.
>
>
>
>   Origin -> Origin Example (t

Re: [alto] Normative References in draft-ietf-alto-performance-metrics-12

[Y. Richard Yang]

Hi Jan, Qin,

Please see below.

On Tue, Jan 12, 2021 at 1:43 AM Qin Wu  wrote:

> Hi, Jan and authors of draft-ietf-alto-performance-metrics:
> -邮件原件-
> 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jan Seedorf
> 发送时间: 2020年11月12日 6:32
> 收件人: alto@ietf.org
> 主题: [alto] Normative References in draft-ietf-alto-performance-metrics-12
>
> Dear authors of draft-ietf-alto-performance-metrics-12,
>
> while reviewing the document, I notices the following issues with
> normative references:
>
> 1)[I-D.ietf-idr-te-pm-bgp]
>Previdi, S., Wu, Q., Gredler, H., Ray, S.,
>jefft...@gmail.com, j., Filsfils, C., and L. Ginsberg,
>"BGP-LS Advertisement of IGP Traffic Engineering
>Performance Metric Extensions", draft-ietf-idr-te-pm-
>bgp-03 (work in progress), May 2016.
>
> --> This is an RFC by now, so please fix the ref
> [Qin]: I think [I-D.ietf-idr-te-pm-bgp] has already been replaced by
> RFC8571 in the v-12 or earlier version.
>

We no longer use this as a reference. So the issue is fixed.



>
> 2)[I-D.ietf-ippm-initial-registry]
>Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
>"Initial Performance Metric Registry Entries", draft-ietf-
>ippm-initial-registry-01 (work in progress), July 2016.
>
> --> this draft is in version -016 by now, and also not a normative
> reference; so please update the ref and move it to informative references
>
[Qin]: Agree, I have checked the reference, I found
> [I-D.ietf-ippm-initial-registry] has been quoted four times but I didn't
> find this reference section 9.1 or section 9.2, I think this issues should
> be fixed.
>

Fixed. Added to informative and it looks to be the latest version -16.

Further note: I fixed the issue of [RFC8571].



> Also IDnits should be fixed as well,
>
> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-performance-metrics-13.txt
> There are 3 nits errors which should be fixed.
>
> All nits except one nit are fixed. It suggested to add an IPv6 example,
and we already have IPv6 examples (e.g., Example 1). Since we added "ipv6:"
prefix, the tool did not detect such examples.


> Can you please address these issues as well when you address the WGLC
> comments received (see below)?
>
>
Thank you so much!

Richard


> Thanks,
>
> Jan
>
> Am 08.11.20 um 22:56 schrieb Jan Seedorf:
> > Dear all,
> >
> > this ends the WGLC for draft-ietf-alto-performance-metrics-12. No
> > objections on this document have been raised. Three individual reviews
> > have been done, the respective comments have each been posted on the
> > ALTO mailing list by Kai (Oct 10), Denny (Oct 12), and Jensen (Oct
> > 13). May I kindly ask the authors of the document to address these
> > comments ASAP and post a new version of the document?
> >
> > Thanks,
> >
> > Jan
> >
> > Am 28.09.20 um 18:42 schrieb Jan Seedorf:
> >> Dear all,
> >>
> >> as discussed during the ALTO session at IETF-108, we are moving
> >> forward with all the remaining milestones.
> >>
> >> Thus, this email starts a WGLC for
> >> draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks,
> >> so from today, Monday, September 28, until Monday, Oktober 12, 2020.
> >>
> >> We would like to have two individual reviews of this document as part
> >> of the WGLC. Please send us an email if you are willing review the
> >> draft as part of WGLC. We really need these reviews to make progress.
> >>
> >>  - Vijay and Jan
> >>
> >> ___
> >> alto mailing list
> >> alto@ietf.org
> >> https://www.ietf.org/mailman/listinfo/alto
> >
> > ___
> > alto mailing list
> > alto@ietf.org
> > https://www.ietf.org/mailman/listinfo/alto
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Jan 12, 2021

[Y. Richard Yang]

Dear Qin, Kai,

Thank you so much for checking. I have updated the document and addressed
all missing comments. A new version is being uploaded now.

Thanks again!
Richard

On Tue, Jan 12, 2021 at 12:57 AM Qin Wu  wrote:

> Hi, Richard:
>
> Thanks for the update on performance metrics draft in v-13, you missed the
> review comments from Kai
>
> https://mailarchive.ietf.org/arch/msg/alto/PQy-QNz6UfTI6GxOPWCzc0VkHRo/
>
> Checking Kai’s comments, I found some of them have been addressed, some of
> them not, e. g.,
>
> 1.Page 15,Example 3
>
> s/delay-var/delay-variation
>
> 2.Page 8
>
> s/with letter p /with letter "p"
>
> 3 Page 6, sec 2.1
>
> remove "and" before sla
>
> s/latency typically do /latency typically does
>
> For Jensen’s comments, I see one issue is newly introduced, i.e., the term
> “metric value” and “metric’s value”
>
> Are used inconsistently, I suggest to change metric’s value into metric
> value.
>
> I hope these comments can be addressed before being moved forward.
>
>
>
> -Qin
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Y. Richard Yang
> *发送时间:* 2021年1月12日 13:36
> *收件人:* Kai Gao 
> *抄送:* alto-weekly-meet...@googlegroups.com; IETF ALTO 
> *主题:* Re: [alto] Meeting Info for Jan 12, 2021
>
>
>
> Hi all,
>
>
>
> I have to skip the meeting this morning.
>
>
>
> One quick update is on the first agenda item: an updated version of
> performance metrics is just posted and we believe that it has addressed all
> of the review comments by Danny and Jensen.
>
>
>
> Richard
>
>
>
>
>
> On Mon, Jan 11, 2021 at 10:36 AM  wrote:
>
> Dear all,
>
>
>
> This is a friendly reminder that we will have an ALTO weekly meeting at *9:00
> am US EST (3:00 pm CET, 10:00 pm Beijing Time) on Jan 12, 2021*.
>
>
>
> Agenda:
>
>
>
> - IETF 110: Working group drafts and individual drafts
>
> - NAI workshop
>
>
>
> If anyone wants to put other topics on the agenda, please let me know or
> use the agenda bash in the beginning of the meeting.
>
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
>
> Best,
>
> Kai
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>

-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Jan 12, 2021

[Y. Richard Yang]

Hi all,

I have to skip the meeting this morning.

One quick update is on the first agenda item: an updated version of
performance metrics is just posted and we believe that it has addressed all
of the review comments by Danny and Jensen.

Richard


On Mon, Jan 11, 2021 at 10:36 AM  wrote:

> Dear all,
>
>
> This is a friendly reminder that we will have an ALTO weekly meeting at *9:00
> am US EST (3:00 pm CET, 10:00 pm Beijing Time) on Jan 12, 2021*.
>
>
> Agenda:
>
>
> - IETF 110: Working group drafts and individual drafts
>
> - NAI workshop
>
>
> If anyone wants to put other topics on the agenda, please let me know or
> use the agenda bash in the beginning of the meeting.
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
> Best,
>
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] 109 recharter working Google doc

[Y. Richard Yang]

+ Moved the discussions to include the mailing list as well, as the
comments and feedback are excellent!

Hi Qin,

Thanks a lot for the comments. Please see inline.

On Mon, Nov 16, 2020 at 7:16 AM Qin Wu  wrote:

> Thanks Richard for the update on multi-domain discussion, I have a few
> questions on this deck of slides:
>
> 1.   RFC7971 provides ALTO deployment consideration, one assumption
> it made is
>
> " The ALTO protocol is designed for use cases where the ALTO server and
> client can be located in
>
> different organizations or trust domains. ALTO is inherently
>
>designed for use in multi-domain environments.  Most importantly,
>
>ALTO is designed to enable deployments in which the ALTO server and
>
>the ALTO client are not located within the same administrative
>
>domain. "
>
> That seems to indicate Multiple administrative domains should be supported? 
> Does the assumption in the RFC7971 still hold?
>
> To my understanding, multiple administrative domains can be supported by 
> Cascaded servers [RFC7971], i.e.,each administration domain
>
> has a ALTO server, ALTO server in another separate domain acting as alto 
> client can query the ALTO server in each domain and aggregate network 
> topology information and exposed to the other ALTO client
>
>
>
> Also ALTO server can get topology data from different data source such as 
> BGP, SNMP, NETCONF,etc in different administrative domain? RFC7752 figure 3 
> provide one of such use cases. It seems multiple domain proposal require
>
> ALTO server to server synchronization, either forward ALTO client request 
> from one server to another server? Or ALTO server in the middle domain send 
> new request to the server in the next domain? The big challenge is to the 
> amountof path information and cost data to be returned can be huge.
>
>
>
> Thanks for making clear the text of RFC7961! Multidomain should still be
the basic environment. The current ALTO services, as they are designed, can
work in a multidomain environment, say using cascading servers, in some
settings. There are two things missing: (1) there is no document specifying
the complete multidomain querying process, which we want to fix; and (2)
the current design can have issues in some multidomain settings; for
example, when conducting cascading query, the downstream ALTO server may
have multiple ingress points for the same flow (e.g., ECS specified by
src/dst IPs). The current design assumes that either the downstream can try
to go upstream to identify the ingress or assume that there is only one
ingress (in some cases can be true). I will make some slides to clarify.


> 2.   I see multi-domain proposal as flow based query, I am wondering how 
> multi-domain proposal is related to flow based query 
> (https://datatracker.ietf.org/doc/draft-gao-alto-fcs/)? Is multi-domain 
> proposal focus on IP layer flow query?
>
>
Good point. If we proceed with generic flow-based queries (ECS and cost map
are IP layer only, and hence are just special cases), we can make
multidomain to be generic flow aware. It looks that generic flow is the
direction of many networks.


> 3.   is there any ALTO protocol extension? E.g., network map
> extension, Cost map extension, or property map extension?
>
>
> Not sure I fully understand the question. Some generic extensions (e.g.,
the one by Sabine) will extend cost map and property map. Is this what you
have in mind?

Thanks again!

Richard


> -Qin
>
> *发件人:* Y. Richard Yang [mailto:y...@cs.yale.edu]
> *发送时间:* 2020年11月13日 8:05
> *收件人:* Chunshan Xiong (Tencent) ; Gang Li (China
> Mobile) ; Yannis (Yunfei) Zhang <
> yanniszh...@tencent.com>; Walid, Anwar (Nokia - US/Murray Hill) <
> anwar.wa...@nokia-bell-labs.com>; Sebastian Kiesel ;
> Randriamasy, Sabine (Nokia - FR) ;
> LUIS MIGUEL CONTRERAS MURILLO ;
> Jensen Zhang ; Kai Gao ;
> Börje Ohlman 
> *抄送:* Qin Wu ; Vijay Gurbani ;
> Jan Seedorf ; Martin Duke <
> martin.h.d...@gmail.com>
> *主题:* Re: 109 recharter working Google doc
>
>
>
> Dear all,
>
>
>
> I made a deck of slides intended to be used for the multidomain discussion
> meeting next week during IETF109. It is attached to this email.
>
>
>
> Any feedback will be highly appreciated. I will send it to the broad
> mailing list as well.
>
>
>
> Richard
>
>
>
> On Wed, Nov 11, 2020 at 10:16 PM Y. Richard Yang  wrote:
>
> Hi all,
>
>
>
> It is exactly one week from tomorrow when we will have the IETF 109
> meeting on ALTO recharter discussions. I cleaned up the Google doc a bit so
> that we all have the same format:
>
>
> https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOa

[alto] Recharter discussion paragraphs link

[Y. Richard Yang]

Dear ALTOers,

The chairs suggested that we collect all of the paragraphs into a single
document, and hence we have created the shared document for our use today:
https://docs.google.com/document/d/1O0x_AaegY9RU9bAVjm9wfWlel-vjOVFlIi9stmz9VXw/edit?usp=sharing

The document will be a live document and we will update it as we go.
Any comments are highly appreciated.

Looking forward to a great meeting soon.

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

Re: [alto] Meeting info for Nov 17, 2020

[Y. Richard Yang]

Hi Qin, Chunshan, Gang,

Yes indeed a post of item 4. What I thought missing is the one paragraph.
Did I miss it :-(

Richard

On Mon, Nov 16, 2020 at 10:48 PM Qin Wu  wrote:

> Richard, Kai:
>
> I think the item 4 has been posted by proponents on the list, which is
> available at
>
> https://mailarchive.ietf.org/arch/msg/alto/9CAIL0hEW4cy90iVeOJn_gYO84o/
>
> we miss item 2 and 3.
>
>
>
> -Qin
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Y. Richard Yang
> *发送时间:* 2020年11月17日 11:02
> *收件人:* Kai Gao 
> *抄送:* alto-weekly-meet...@googlegroups.com; IETF ALTO 
> *主题:* Re: [alto] Meeting info for Nov 17, 2020
>
>
>
> Thanks a lot, Kai!
>
>
>
> I saw from the WG mailing list the proposed paragraphs on items 1 and 5.
> It will be nice if the leads of 2-4 can post the initial proposals before
> the meeting soon...
>
>
>
> Richard
>
>
>
> On Mon, Nov 16, 2020 at 8:17 AM  wrote:
>
> Dear all,
>
> We will have the last meeting before the IETF 109 ALTO session at 9:00 am
> US EST (3 pm CET, 10 pm Beijing Time).
>
> The purpose is to go over and finalize the recharter items. Given that
> some topics were not presented in the last meeting, I suggest we follow the
> order below:
>
> 1. General extensions
>
> 2. New transport
>
> 3. Operation automation
>
> 4. First hop
>
> 5. Multi-domain
>
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
>
> Best,
>
> Kai
>
> _______
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>
>
>
> --
>
> --
>
>  =
>
> | Y. Richard Yang|
>
> | Professor of Computer Science   |
>
> | http://www.cs.yale.edu/~yry/|
>
>  =
>
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting info for Nov 17, 2020

[Y. Richard Yang]

Thanks a lot, Kai!

I saw from the WG mailing list the proposed paragraphs on items 1 and 5. It
will be nice if the leads of 2-4 can post the initial proposals before the
meeting soon...

Richard

On Mon, Nov 16, 2020 at 8:17 AM  wrote:

> Dear all,
>
> We will have the last meeting before the IETF 109 ALTO session at 9:00 am
> US EST (3 pm CET, 10 pm Beijing Time).
>
> The purpose is to go over and finalize the recharter items. Given that
> some topics were not presented in the last meeting, I suggest we follow the
> order below:
>
> 1. General extensions
>
> 2. New transport
>
> 3. Operation automation
>
> 4. First hop
>
> 5. Multi-domain
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
> Best,
>
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

[Y. Richard Yang]

Hi Sabine,

Thanks a lot for the paragraph describing a potential recharter item.

I have three quick comments, according to my understanding:

- [C1] The extension will focus on "additional" information such as
conditions/context on entities (e.g., extend unified properties) and path
costs (e.g., extend endpoint cost services, cost map services). I can see
such a capability as an instance of a generic capability to allow more
efficient information distribution; that is, instead of asking the server
each every time, the client is given the condition/policy and the
information, and the client can decide, locally, whether to use the
information (and/or what information is applicable). I see two benefits:
(1) reduce the latency for the client to query (and reduce server load
during congestion), and (2) potentially reduce information (e.g., instead
of A, B, A, B from server to client when the condition/context switches
between two states, the server send A and B and the condition to watch
for). Is this the right way to understand the benefits of the item? If so,
it may help to add sentences on the issues that the item addresses (e.g.,
low efficiency of information distribution)?

- [C2] If the preceding understanding is correct, then maybe the item can
be described using a more specific term, instead of the generic term of
general protocol extension. Also, the condition/context still appears to
help a client to decide "where" and "when" to connect but also under which
conditions, with the "when" being understood in both temporal (time) and
logical senses. Hence, I feel that some clarification of the term can help.

- [C3] Moving from the "problem" (why) part to the "feasibility" (how)
part. How about we constrain the design space some more? For example, one
can envision using the power of the full mathematical logic (simple Boolean
logic, temporal logic, ...) to specify the context/conditions. This can be
powerful but also may be complex to finish in a target time frame of say
only 1-2 years.

Talk to you tomorrow and we can go over some more details to wrap up.

Richard

On Mon, Nov 16, 2020 at 12:35 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hello,
>
>
>
> Please find below a revision of the proposed definition paragraph.
>
> This WG item is further detailed in the Google doc available here (page
> 19/25):
>
>
> https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit
>
>
>
> Thanks,
>
> Sabine
>
>
>
> 
>
> General protocol extensions to convey a richer set of attributes allowing
> to determine not only "where" and "when" to connect but also under which
> conditions. Such additional information will be related both to entities
> (e.g. conveying time-averaged server load in data center supported
> applications) and to path costs (e.g. ALTO path cost value depending on
> conditions such as real-time network indications or SLA or policy or
> access-type or indicator type).
>
>
>
> The working group will specify such extension in coordination with both
> other ALTO working group items and IETF working groups that have a focus on
> the related use cases.  The scope of extensions is not limited to those
> identified by the WIs and WGs, but is limited by the criteria set out below.
>
> 
>
>
>
>
>
> *From:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>
> *Sent:* Monday, November 16, 2020 6:16 PM
> *To:* Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <
> sabine.randriam...@nokia-bell-labs.com>; IETF ALTO 
> *Subject:* RE: ALTO recharter: proposed item - General ALTO protocol
> extensions
>
>
>
> Dear all,
>
>
>
> The paragraph below is proposed to define the WG item on “general protocol
> extensions”.
>
> As the purpose of this work item is also to support other WG items that
> may need these extensions, your feedback again is more than welcome.
>
> Thanks,
>
> Sabine
>
>
>
> General protocol extensions to convey a richer set of cost attributes
> allowing to determine not only "where" and "when" to connect but also under
> which conditions. Such additional information will be related both to
> entities (e.g. conveying time-averaged (cache storage capacities and)
> server load in data center supported applications) and to ALTO path costs
> (e.g. ALTO path cost value depending on conditions such as real-time
> network indications or SLA or policy or access-type or indicator type).
>
>
>
> The working group will specify such extension in coordination with both
> other ALTO working group items and IETF working groups that have a focus on
> the related use cases.  The scope of extensions is not limited to those
> identified by the WIs and WGs, but is limited by the criteria set out below.
>
> 
>
>
>
> *From:* alto  *On Behalf Of *Randriamasy, Sabine
> (Nokia - FR/Paris-Saclay)
> *Sent:* Tuesday, November 

Re: [alto] ALTO recharter update: ALTO services in multi-domain settings

[Y. Richard Yang]

Addressing some comments I received and following the same format as Sabine
did, I post the paragraph below:

Extension of ALTO services to support multi-domain settings. The current
ALTO framework focuses on providing network information from a single ALTO
server for a single network (administrative domain), but the network
devices traversed by a flow can be managed by multiple networks not in the
same domain. The working group will investigate and extend the ALTO
framework to (1) enumerate the issues of ALTO services involving network
paths spanning multiple domains with multiple ALTO servers, and (2)
introduce capabilities to query ALTO services for the settings. The working
group should specify complete ALTO multi-domain services, by using existing
services whenever possible. The working group should consider realistic
complexities including incremental deployment, dynamicity, core security
issues including access control, authorization (e.g., an ALTO server
provides information for a network that the server has no authorization),
and privacy protection in multi-domain settings.

Additional info will be discussed in the slides to be discussed in the
weekly meeting tomorrow and then during the meeting later this week.

Any comments are highly welcome.

Richard

On Thu, Nov 12, 2020 at 7:10 PM Y. Richard Yang  wrote:

> Dear ALTOers,
>
> Please see attached an updated version of the slides intended to
> contribute to the multidomain item. The slides are team efforts. Any
> feedback, comments, suggestions are highly welcome. We see that alternative
> designs such as architectures are feasible as well, but we want to post the
> initial design to make clear the problem and feasibility.
>
> Thanks!
> Richard
>
> On Tue, Nov 10, 2020 at 4:12 PM Y. Richard Yang  wrote:
>
>> Dear ALTOers,
>>
>> One item which we discussed this morning during our weekly meeting is
>> ALTO extension to multi-domain settings. Please see attached for the deck
>> of slides that we used.
>>
>> At a high level, it tried to extend ALTO into a multi-domain setting for
>> one of the most basic ALTO services --- endpoint cost services. One item
>> which was raised, but not included in the slides is to make clear the use
>> cases, i.e., how the multiple-domain information is used. We sure will
>> update soon, before and during the WG meeting. Any questions and/or
>> comments are highly welcome.
>>
>> Richard
>>
>

-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO recharter update: ALTO services in multi-domain settings

[Y. Richard Yang]

Dear ALTOers,

Please see attached an updated version of the slides intended to contribute
to the multidomain item. The slides are team efforts. Any feedback,
comments, suggestions are highly welcome. We see that alternative designs
such as architectures are feasible as well, but we want to post the initial
design to make clear the problem and feasibility.

Thanks!
Richard

On Tue, Nov 10, 2020 at 4:12 PM Y. Richard Yang  wrote:

> Dear ALTOers,
>
> One item which we discussed this morning during our weekly meeting is ALTO
> extension to multi-domain settings. Please see attached for the deck of
> slides that we used.
>
> At a high level, it tried to extend ALTO into a multi-domain setting for
> one of the most basic ALTO services --- endpoint cost services. One item
> which was raised, but not included in the slides is to make clear the use
> cases, i.e., how the multiple-domain information is used. We sure will
> update soon, before and during the WG meeting. Any questions and/or
> comments are highly welcome.
>
> Richard
>


slides-ietf109-recharter-multidomain.pptx
Description: MS-Powerpoint 2007 presentation
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Any implementations of unified-props, alto-cdni, path-vector

[Y. Richard Yang]

Hi Vijay,

- I believe that there was an implementation of unified properties by Wendy
Roome. But it is for an earlier version, not the latest one which we just
posted.

- I understand that there was an implementation of path vector used in
super computing demonstration; but it was for an earlier version of path
vector without the integration of unified properties.

Richard

On Thu, Nov 12, 2020 at 12:43 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Vijay,
>
>
>
> To my knowledge,
>
>
>
> - there is no implementation of Unified Properties that reflects the
> latest design updates, defined in 2019 and 2020,
>
> - I am not aware of any implementation of Path Vector.
>
>
>
> Best regards,
>
> Sabine
>
>
>
> *From:* alto  *On Behalf Of *Vijay Gurbani
> *Sent:* Wednesday, November 11, 2020 5:57 PM
> *To:* IETF ALTO 
> *Subject:* [alto] Any implementations of unified-props, alto-cdni,
> path-vector
>
>
>
> All: I am the shepherd for the three drafts identified in the subject.
>
>
>
> As I prepare the shepherd writeup, I will like to document if there are
> any implementations of these three drafts that the WG members are aware
> of.  These implementations can be private (a few individuals working on the
> drafts), or be more formal with a GitHub repository and a larger community.
>
>
>
> If any WG member is aware of implementations, please let me know.  Please
> drop me an email (or  post on the list) with the details as you know them.
> I would like to kindly ask you to do this as soon as possible ---
> preferably by the end of this week --- to allow me to prepare the shepherd
> writeup.
>
>
>
> Thank you.
>
>
>
> - vijay
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Welcome Qin Wu

[Y. Richard Yang]

Thanks a lot for choosing a wonderful chair for ALTO, Martin!

Qin: It is wonderful to have you and work with your guidance!

Richard

On Mon, Nov 9, 2020 at 10:48 PM Martin Duke  wrote:

> Hello ALTO,
>
> I'm pleased to welcome Qin Wu as the newest working group chair, effective
> immediately. Qin is and active participant in ALTO and an experienced chair.
>
> We will have three chairs at IETF 109. Shortly afterwards, one of the
> current chairs will step down. As we complete the current milestones, I
> will appoint a second chair to free both Jan and Vijay to move on to other
> things.
>
> See you next week,
> Martin
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO recharter update: ALTO services in multi-domain settings

[Y. Richard Yang]

Dear ALTOers,

One item which we discussed this morning during our weekly meeting is ALTO
extension to multi-domain settings. Please see attached for the deck of
slides that we used.

At a high level, it tried to extend ALTO into a multi-domain setting for
one of the most basic ALTO services --- endpoint cost services. One item
which was raised, but not included in the slides is to make clear the use
cases, i.e., how the multiple-domain information is used. We sure will
update soon, before and during the WG meeting. Any questions and/or
comments are highly welcome.

Richard


alto-multidomain-2020-11-10.pptx
Description: MS-Powerpoint 2007 presentation
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IMPORTANT: Suggestions for IETF 109 ALTO meeting

[Y. Richard Yang]

Hi Vijay, Jan,

Wonderful suggestion and organization!

As a regular attendee of the Wed (lately it changed to Tuesday as well)
meetings, I agree that the meetings members should focus on making progress
on the charter text and . We will send more updates soon.

Thanks again!

Richard

On Thu, Nov 5, 2020 at 10:36 AM Vijay Gurbani 
wrote:

> All: We plan to devote most of the time during our IETF 109 slot to
> charter discussions.
>
> Approaching the rechartering discussion in the manner we did during IETF
> 108 was not very conducive as most of the time was spent in 10 - 16 slide
> shows. The WG decided that we will hold a virtual interim to make progress
> towards 3-5 items that can be chartered under a new charter.  Clearly a
> virtual interim did not happen, but work towards winnowing down the charter
> items has been going on in the Wed meeting that a subset of the WG
> organizes weekly.
>
> The intent of the meeting slot in IETF 109 will be to make progress
> towards rechartering, which concretely implies that we have some charter
> text to discuss and that this includes 3-5 milestones that the rechartered
> WG will decide to pursue.
>
> Writing a charter text is an art form, so my advice to the Wed meeting
> group will be to devote the remaining meetings to come up with a candidate
> charter text.  It won't be perfect, but it will be a starting point to host
> discussions on re-chartering during IETF 109.  Please make sure that you
> have 3-5 deliverables in the charter along with reasonable milestones.
> Each piece of work that goes into a charter should have some thoughts
> behind it, or some candidate drafts.
>
> I don't expect IETF 109 to be the end of charter discussion, but rather it
> will be the first formal introduction of the WG to the charter and should
> kick off the process to arrive at a charter that has consensus of all
> relevant parties involved.
>
> Please let Jan and me know if there are any questions.
>
> Thanks,
>
> - vijay
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
-- 
Richard
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO multidomain extension

[Y. Richard Yang]

Dear ALTOers,

During the weekly meeting yesterday, one issue discussed is an extension of
ALTO to multidomains. This is a relevant issue and investigated by Ingmar,
Sebastian, Kai and Qiao. Below is a proposal to get the WG feedback.

Problem: Consider a basic ALTO service say the endpoint-cost service (ECS).
The client has a set of (srci, dsti) pairs which we call flows, and a
performance metric m; the client wants to query the system to receive the
value of m for each flow. The existing ALTO framework solves the issue in
the context of a single domain network as follows:

- Use ALTO service discovery (using an address say srci) to find the single
ALTO server
- Send the ECS query to the server

The preceding will not work if the {(srci, dsti)} span multiple networks.
Consider the simplest case of only one flow, but the path of the flow spans
multiple networks: assume src is in network 1,

src ---> net1-int > net1-egress ---> net2-ingress > net2-int --->
dst,

then the information does not come from a single network (via its ALTO
server), but should come from multiple segments, assuming that there is not
an aggregator ALTO server sering both net1 and net2, Hence, it is a
relevant issue that we should solve.

To show that this is not a research problem because it has no solution yet,
the team designed an initial solution which should address the following
two tasks:

[T1] first, we need a solution to discover that the path from a src to a
dst.
[T2] given a network, the query will no longer be from the src to the dst,
but from a given ingress.

A first solution demonstrating the feasibility is the following:

- [E1] For a given network, add a new ALTO service with
  input: a flow, its ingress to the network
  output: the egress of the flow from the network, and the ingress of the
network
  // To address issue that there can be internal addresses (e.g.,
net1-egress, net1-ingress), we design that the return includes a network
identifier

- [E2] Extend basic (full path) cost service to collect segment cost.

Basic single flow case:

  input: a flow, its ingress to the network. [egress of this network;
ingress-next]
  output: the cost (metric m) of the flow traversing the segment from
ingress to egress
 // comment: missing the segment from egress to next ingress; in general
case, we can include the segment from ingress to next ingress for
consistency but the WG can discuss this issue for final design.

General multi flows, as the original cost service. Then the client using E1
can construct a flow graph from all flows specified in the original ECS
query, e.g.,

 src1 ---> net1-int ---> net1-egress ---> net2-ingress ---> net2-int -->
dst1
^
 \
   /
  \
 src2 --> net1-int  -
net2-int --> ...


For the same network, the client collects all sgements traversing the
network and issue a single query. Note that this makes the original cost
services just c a special case.

[E3] Instead of client conducting aggregation (aka DNS iterative), the
client can request an aggregator like query (aka DNS recursive). Single the
aggregator may not be able to aggregate data from different networks for
some metrics (e.g., internal-cost), the results will be a vector instead of
a single number.

We will go over some details during the recharter discussion in 2 weeks but
want to share this simple, clean design first with the WG to seek feedback.

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