Re: [alto] Review of draft-ietf-alto-path-vector-11

[Vijay Gurbani]

Dear Kai: Thank you.  I will perform a chair review of -13 as part of the
shepherd writeup.
Thanks,
- vijay

On Thu, Nov 19, 2020 at 3:47 AM  wrote:

> Hi Jan, Vijay and Qin,
>
>
> As we discussed in the ALTO meeting today, -12 has addressed the comments
> of both Qiao and Luis but the revision proposed by Richard was not
> integrated. Also, Qin mentioned that a shorter and more concise abstract is
> expected.
>
>
> I have integrated the revisions of Richard and written a new abstract as
> below. Could you please take a look and see if the abstract makes sense? If
> it does, I will upload -13 once the submit tool is available.
>
>
> Thanks for the comments and looking forward to your feedback!
>
>
> Best,
>
> Kai
>
>
> --
>
>The performance of many applications, such as large-scale data
>transfers and/or mobile applications, depends on the properties of
>different components of networks.  Thus, such information is useful
>to help clients better determine the choices of delivering traffic,
>e.g., by avoiding shared bottlenecks.  This document extends the base
>Application-Layer Traffic Optimization (ALTO) protocol with a graph
>representation format using path vectors.  It 1) complements existing
>path-based ALTO cost map representation with the ability to specify
>components of networks for a source and a destination, and 2) uses
>the ALTO property map to associate these components to their
>properties.  Together, this extension provides a more complete but
>still abstract representation of networks for informed traffic
>optimization among endpoints.
>
>
> 2020-11-03 06:04:06"'Richard Yang'" wrote:
>
> H Luis,
>
> Thanks a lot for the wonderful review! As we upload the revision, here is
> a summary of the changes that we make. Please see inline to see if you are
> OK. After you approve, we will finalize all.
>
> On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com> wrote:
>
>> Hi all,
>>
>>
>>
>> I have performed a review of the draft, with comments as follows:
>>
>>
>>
>> /* Technical comments */
>>
>> .- Section III Terminology – Path Vector bullet. Please, rephrase the
>> description, it is hard to understand, especially the second sentence. Not
>> clear.
>>
>
> OLD
>  Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
>   of ANE Names.  It conveys the information that the path between a
>   source and a destination traverses the ANEs in the same order as
>   they appear in the Path Vector.
>
> NEW
>
> Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
>   of ANE Names.  This extension (i.e., ALTO path vector extension)
> generalizes
>   BGP path vector, where a standard BGP path vector specifies the
> sequence of
>   autonomous systems from a source to a destination. In this
> extension, the path
>   vector specifies the sequence of general ANEs computed according to
> a user
>   request.
>
> .- Section 4.2 – it refers to recent use cases, but it is not relevant how
>> recent are the use cases (in fact, for this, see my next comment). So I
>> would suggest to remove any reference to recent either in the title or the
>> text. Simply refer to use cases.
>>
>
> Very good point. We have removed the word "recent" in the title and the
> text.
>
>
>
>> .- Section 4.2 – there is a reference to an expired I-D which last from
>> 2013 (so pretty old). I would suggest to remove such a reference since
>> somehow the potential use cases it refers should be present here.
>>
>
> Sounds good. Yes. Removed.
>
>
>> .- Section 5.1.3, 2nd paragraph – “… and the response must return and
>> only return the selected properties …” – two comments here: (1) must should
>> be MUST in this context?; (2) “… and only return …” – probably redundant,
>> better either remove or rephrase as “MUST/must only return”.
>>
>
> Good point.
>
> OLD
>"... and the
>response must return and only return the selected properties for the
>ANEs in the response."
>
> NEW
>   "... and the
>response MUST include and only include the selected properties
> specified in the filter. "
>
> .- Figure 4 – the figure shows two response messages, but some questions
>> arise in this respect: (1) what happens if second response is not
>> received?; (2) what happens if only the second response is received? Is it
>> silently discarded?; (3) is there some expected timer for accounting
>> time-out in the responses? It is mentioned in bullet 2 that there could be
>> some processing among messages, so it can be assumed that some maximum
>> delay could happen between both responses.
>>
>
> Good point.
>
> OLD
>   Specifically, the
>Path Vector extension requires the ALTO client to include the source
>and destination pairs and the requested ANE properties in a single
>request, and encapsulates both Path Vectors and properties associated
>wit

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

[internet-drafts]

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

Title   : ALTO Extension: Path Vector
Authors : Kai Gao
  Young Lee
  Sabine Randriamasy
  Yang Richard Yang
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-path-vector-13.txt
Pages   : 47
Date: 2020-11-20

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


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

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

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


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

Re: [alto] Review of draft-ietf-alto-path-vector-11

[Qin Wu]

发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2020年11月20日 13:39
收件人: Qin Wu 
抄送: alto@ietf.org; Jan Seedorf ; Vijay Gurbani 

主题: Re: RE: Re: [alto] Review of draft-ietf-alto-path-vector-11


Hi Qin,



Thanks for the comments.



I took a look at the new RFCs (SSE and Cost Calendar). My impression is that 
their abstract mainly focuses on the benefits and high-level ideas of the 
extension. I try to follow the same structure and modify the abstract based on 
your proposed text:



This document is an extension to the base Application-Layer Traffic

Optimization (ALTO) protocol. It extends the ALTO Cost Map service

and ALTO Property Map service so that the application can decide

which endpoint(s) to connect based on not only numerical/ordinal cost

values but also details of the paths. This is useful for applications whose

performance is impacted by specified components of a network on the

end-to-end paths, e.g., they may infer that several paths share common

links and prevent traffic bottlenecks by avoiding such paths. This extension

introduces a new abstraction called Abstract Network Element (ANE) to

represent these components and encodes a network path as a vector of

ANEs. Thus, it provides a more complete but still abstract graph representation

of the underlying network(s) for informed traffic optimization among endpoints.



Also, I feel it might be a good idea to add a sentence in the end to link to 
the corresponding charter item (e.g., "Together, they provide a more complete, 
potentially more compact, but still abstract representation of networks for 
informed traffic optimization among endpoints.").



Does the proposed text make sense? Looking forward to your feedback!

[Qin]: Kai, the proposed change looks good, thanks for polishing it.

Thanks!



Best,

Kai


-Original Messages-
From:"Qin Wu" mailto:bill...@huawei.com>>
Sent Time:2020-11-19 20:18:34 (Thursday)
To: "kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>, 
"alto@ietf.org" mailto:alto@ietf.org>>
Cc: "Jan Seedorf" 
mailto:jan.seed...@hft-stuttgart.de>>, "Vijay 
Gurbani" mailto:vijay.gurb...@gmail.com>>
Subject: RE: Re: [alto] Review of draft-ietf-alto-path-vector-11
Thanks Kai Gao for heads up.

I feel the abstract in the path vector is too long, I propose to have the 
following changes to the abstract:

"

   This document is an extension to the base Application-Layer Traffic

   Optimization (ALTO) protocol. It extends the ALTO Cost Map service and

   ALTO property Map service so that the application can decide which endpoint

   to connect but also which connection path to select.



   This is useful for applications whose performance is impacted by specified 
Network Elements of end to end path

   they traverse or by their properties, e.g., they may infer that several 
paths share common links

   and prevent traffic bottlenecks by avoiding such paths. Examples of such 
Elements include

   physical devices such as routers, cables and

   interfaces, and aggregations of devices such as subnetworks and data

   centers. Example of such properties include network elements id, link id.



   This extension introduces a new cost type called Path Vector.  A Path Vector 
is

   an array of entities that each identifies an Abstract Network Element (ANE).

   Each ANE is associated with a set of properties.  ANE properties are 
introduced and conveyed by

   an ALTO information resource called "Property Map", that can be

   packed together with the Path Vectors in a multipart response.  They

   can also be obtained via a separate ALTO request to a Property Map.

"

-Qin
发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2020年11月19日 17:47
收件人: alto@ietf.org
抄送: Jan Seedorf 
mailto:jan.seed...@hft-stuttgart.de>>; Vijay 
Gurbani mailto:vijay.gurb...@gmail.com>>; Qin Wu 
mailto:bill...@huawei.com>>
主题: Re: Re: [alto] Review of draft-ietf-alto-path-vector-11


Hi Jan, Vijay and Qin,



As we discussed in the ALTO meeting today, -12 has addressed the comments of 
both Qiao and Luis but the revision proposed by Richard was not integrated. 
Also, Qin mentioned that a shorter and more concise abstract is expected.



I have integrated the revisions of Richard and written a new abstract as below. 
Could you please take a look and see if the abstract makes sense? If it does, I 
will upload -13 once the submit tool is available.



Thanks for the comments and looking forward to your feedback!



Best,

Kai



--

   The performance of many applications, such as large-scale data
   transfers and/or mobile applications, depends on the properties of
   different components of networks.  Thus, such information is useful
   to help clients better determine the choices of delivering traffic,
   e.g., by avoiding shared bottlenecks.  This document extends the base
   Application-Layer Traffic Opti

Re: [alto] Unified properties terminology clarification

[Qin Wu]

Thanks Wendy for clear clarification and thanks Sabine for proposed change, the 
proposed change adds more clarity, looks good to me, thanks!

-Qin
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2020年11月20日 3:03
收件人: Wendy Roome ; Qin Wu ; alto@ietf.org
主题: RE: [alto] Unified properties terminology clarification

Hi Wendy and Qin,

Along your lines, my take is that this document extends the protocol in two 
major directions:
- from endpoints restricted to IP addresses to entities covering a wider and 
extensible set of objects,
- from properties on specific endpoints to entire entity property maps.
The document introduces additional features allowing entities and property 
values to be specific to a given information resource. This is made possible by 
a generic and flexible design of entity and property types.

So we may entitle the document w.r.t. the two major evolutions.
Do you think that the title  “ALTO extension: entity property maps” is suitable?
@ Richard and Kai: what is your opinion?

Thanks,
Sabine


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Wendy Roome
Sent: Thursday, November 19, 2020 5:19 PM
To: Qin Wu mailto:bill...@huawei.com>>; 
alto@ietf.org
Subject: Re: [alto] Unified properties terminology clarification

Hi, Qin!

I'm Wendy Roome, and I wrote the original version of this draft. I stopped 
being active in this group after I retired in 2017, but I can describe the 
motivation for the title.

Back then, we had "costs" between pairs of "entities," and we were expanding 
the concept of "entities" to include more than just PIDs & IP addresses. We 
also had GET requests to return entire maps, and POST requests to return a 
filtered subset.

We also had a property service, but it was very restricted: it only applied to 
endpoints, it could not be extended, and it only allowed POST requests for 
specific endpoints rather than GET requests for an entire set. Furthermore, 
when I implemented the protocol, I suspected that many "properties" would 
really be associated with CIDRs or PIDs, rather than individual endpoints, and 
the endpoints would inherit those properties.

My goals were to make "properties" as extensible as costs, to provide the same 
choice of GET-mode for complete maps and POST requests for subsets, and to 
define an inheritance mechanism. That is, I wanted to "unify" properties and 
costs. Hence the original title. If that name no longer fits, by all means 
change it!

- Wendy Roome

From: alto mailto:alto-boun...@ietf.org>> on behalf of 
Qin Wu mailto:bill...@huawei.com>>
Date: Thu, November 19, 2020 at 07:33
To: "alto@ietf.org" mailto:alto@ietf.org>>
Subject: [alto] Unified properties terminology clarification

Hi, Sabine:
Follow up our discussion in today’s ALTO session, one issue I raised is about 
the terminology we used in the unified properties draft. I feel the term 
“unified properties” lacks clarity and causes a little bit confusion to people 
who are familiar with this draft, that is on is unified property break existing 
protocol or component such as
Endpoint property, I am wondering if we can change the term into property Map, 
so the title will be changed into “ALTO extension: Property Map” , which is 
also align with the title of Path vector draft, Does this make sense?
As you mentioned, this was discussed in the past, can you remind me the history 
discussion why the current name is picked. Thanks in advance, hope we can 
resolve this as soon as possible.

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