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

Vijay Gurbani <vijay.gurbani@gmail.com> Fri, 20 November 2020 15:35 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424683A0D06 for <alto@ietfa.amsl.com>; Fri, 20 Nov 2020 07:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epIt-L2Vri96 for <alto@ietfa.amsl.com>; Fri, 20 Nov 2020 07:35:46 -0800 (PST)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429ED3A0D21 for <alto@ietf.org>; Fri, 20 Nov 2020 07:35:46 -0800 (PST)
Received: by mail-yb1-xb2c.google.com with SMTP id t33so8964787ybd.0 for <alto@ietf.org>; Fri, 20 Nov 2020 07:35:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b76W75qD0ZZwKd0/yVtP9GsKqyCROvKKEvYCplXSgis=; b=jTjW/QaNIyos7LZoF3uqZwNHzLIZcpNO/CTiYUYZqMBprWouzRWHlyh+iIWG5VOf1j PywNKH2J5m3p2imn2Md9SA8gy4VwipdQTxCU+30sbD19ghbY3TFOxpMG23D5Zb1JhWqQ s5RL8oUL/Uvmyew2UgHW2Z7DzTRy5blDC/QvKQ9rbUSRyL5qBYgr2kHCM7GCwahQpfuv CIFRADsf3CiEQJaFcAyzYA5cFOWZsFsKQuaOMVkx2XGE9GgXXobpJlD/6AE5HkbYZLWp cvFLZgdcz25DZIGCZAB6wN5GlYRo0bJOakny23zl74tN3hmcbuB9hamnubBiR7bIYA0e Ahuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b76W75qD0ZZwKd0/yVtP9GsKqyCROvKKEvYCplXSgis=; b=i1ibxgtOhJ2AuaBWtDi17MHE5VS+2yLUE+3LaTbNNj62qomMwmuhJU7JF8JEMdniBR yeA+fBLTEeYHJzGe+6zPdVLfGjBeGkwr9gtrRkE3MKSvzf1ud1+wAWW95QbQMsjFBGFJ 9UYKvzRDGlIsW6M6/8eMgTolVfZ8GgZoAAfJq116+YamMC9p+PbwbPlQi/SbD52lx8NY aipDA/Wx+0BbHmOPEFoc3lAyvsInyu4aWyYghlY5dKb/ma2m+sevguiaR8rgxyEcifg2 fBS3Gw4Cjbx6munw/BudkgUsXswGs8zKOIUZe+m9fT58F9oYt3AgKdARKgy7KmBQ8+n1 Ndkg==
X-Gm-Message-State: AOAM532JRVpumduPsTgK3CHagoHvyXvp/7Z7TYY8GgC2fSecnljbN9bL 9bYSHKo6+D/2QqtNOs02BQ+i1mdSQdvpO6wEnWI=
X-Google-Smtp-Source: ABdhPJw68gcELxox+dC8hJT8U1R17iCJZV6HLIsooEzD1fN1pazcDGTO6kvEatcADnn9I71w1QLwIofZnBK8Kxa2erw=
X-Received: by 2002:a25:2495:: with SMTP id k143mr17720396ybk.396.1605886545379; Fri, 20 Nov 2020 07:35:45 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0601MB215782B6074A1EC39A47F6EA9E180@VI1PR0601MB2157.eurprd06.prod.outlook.com> <CANUuoLqf4Fyg7XQBzfc=2zVV28zK4COfiOH4eZz6ay7L8G1ynA@mail.gmail.com> <3b9d983e.187b0.175dfe6c9b9.Coremail.kaigao@scu.edu.cn>
In-Reply-To: <3b9d983e.187b0.175dfe6c9b9.Coremail.kaigao@scu.edu.cn>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Fri, 20 Nov 2020 09:35:07 -0600
Message-ID: <CAMMTW_L-28p=ZMeqNQvLeC-P=ONT-=Q9yUUgyjYW76tXy7u4hw@mail.gmail.com>
To: Kai Gao <kaigao@scu.edu.cn>
Cc: "alto@ietf.org" <alto@ietf.org>, Jan Seedorf <jan.seedorf@hft-stuttgart.de>, Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000001645cc05b48b99a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/atj7diyWMjo3W5THzbcLxf1dXGI>
Subject: Re: [alto] Review of draft-ietf-alto-path-vector-11
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2020 15:35:49 -0000

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 <kaigao@scu.edu.cn> 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'" <yry@cs.yale.edu>wrote;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.contrerasmurillo@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.contrerasmurillo@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 <yry@cs.yale.edu>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/        |
>  =====================================
>
>