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!
Thanks!
Best,
Kai
-----Original Messages-----
From:"Qin Wu" <bill...@huawei.com>
Sent Time:2020-11-19 20:18:34 (Thursday)
To: "kai...@scu.edu.cn" <kai...@scu.edu.cn>, "alto@ietf.org" <alto@ietf.org>
Cc: "Jan Seedorf" <jan.seed...@hft-stuttgart.de>, "Vijay Gurbani"
<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 <jan.seed...@hft-stuttgart.de>; Vijay Gurbani
<vijay.gurb...@gmail.com>; Qin Wu <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 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'" <y...@cs.yale.edu>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
with the ANEs in a single response, as shown in Figure 4.
NEW
Specifically, the
Path Vector extension requires that (1) the ALTO client include the source
and destination pairs and the requested ANE properties in a single
request; (2) the ALTO server MUST return a single response with the Path
Vectors followed by the
properties associated with the ANEs in the Path Vectors, as shown in Figure
4.
In addition, in 5.3.3, we add the specification on the essential completeness
issue:
OLD
5.3.3. Order of Part Message
NEW
5.3.3. Order and Completeness of Part Message
We add a sentence at the end of 5.3.3
The ALTO server MUST always send the complete response including both parts.
The client should check the completeness of response and implementing a timeout
mechanism to avoid hanging issues.
.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please,
rephrase/review.
OLD
Specifically, the defining resource of ephemeral ANEs is the Property
Map part of the multipart response. The defining resource of
persistent ANEs is the Property Map on which standalone queries for
properties of persistent ANEs are made.
NEW
Note that there are two types of ANEs (see Section 5.1.2): ephemeral ANEs and
persistent ANEs. For ephemeral ANEs, the defining resource is the Property
Map part of the multipart response; the defining resource of
persistent ANEs is the Property Map on which standalone queries for
properties of persistent ANEs are made.
.- Section 6.4.2, Intended semantics text – it is not clear the association of
persistent to ephemeral. Why is this? What is the purpose?
.- Section 6.4.2, last paragraph – The value of ephemeral is provided, but what
would be the value of persistent one?
It looks that we need a bit more update. We will finalize the update shortly.
.- Section 9.3, 1st and past paragraph – they seem inconsistent since in one
hand the first claims incompatibility while the second claims compatibility.
Please, review them.
As SSE is finalized now, we will update this part shortly.
.- Section 9.4 – When used with the calendar extension, should the ANE be
always persistent? I mean, same ANE for all the time views, otherwise could not
properly work. Please, clarify.
It should. We will update.
/* Editorial comments */
.- Section I Introduction, pag. 5, penultimate paragraph – “… Path Vector
response involve two ALTO …” -> “… Path Vector response involves two ALTO …”
Good catch. Fixed.
.- Section I Introduction, pag. 5, last paragraph – “… the rest of the document
are organized …” -> “… the rest of the document is organized …”
Good catch. Fixed.
.- Section III Terminology stands that the document extends the terminology
used in RFC 7285 and in Unified Properties draft. This implies some precedence
in the edition of the documents as RFCs, if they finally progress to that
stage. So I would recommend to add a note for RFC Editor mention that
precedence (note to be remove once the document becomes a RFC).
Good idea. Unified, which is newer, should have precedence.
.- Section 5.1 – the text (2nd paragraph) auto-refers to section 5.1.
Redundant, better to remove.
Fixed.
.- Section 5.2 – 1st paragraph – correct -> correctly
Fixed.
.- Section 5.3, last sentence before Figure 4 – “… the ANEs in a single
response …” -> “… the ANEs in an additional response …”
Fixed.
.- Section 6.6 – The second paragraph starts with NOTE; probably better to
rephrase writing it as a normal paragraph.
Chaned to "Note that ..."
.- Section 9.2, last sentence – “compatible” -> “compatibility”
Good catch. Fixed.
Thank you so so much!!
Richard
Best regards
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 <y...@cs.yale.edu> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto