[alto] Chair review of path-vector-13 (Part 2 of 2)

Vijay Gurbani <vijay.gurbani@gmail.com> Wed, 10 February 2021 16:24 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CDD963A0F0F; Wed, 10 Feb 2021 08:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hdvhm5evywxx; Wed, 10 Feb 2021 08:24:27 -0800 (PST)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 D29313A0F39; Wed, 10 Feb 2021 08:24:26 -0800 (PST)
Received: by mail-yb1-xb36.google.com with SMTP id y128so2554812ybf.10; Wed, 10 Feb 2021 08:24:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=3xWLlOu9eSASoy6eXzt+azKM4r8qeRmNVdc/W+4eGpw=; b=t3w+ECqPaLv7TzgLVqL3o+Qu4iY/YywevfLsfpQvrHs6Lgn/ElXUPaGbr/jKMQtMJg x9QByxxsno0F0v8LrNLKgEVXTjbTi28lkUOjXXiYo/yUgvLzsZACyUJFZo+sxSIv0wfU 22itwrqw1C2+TArgu/zQWynXHUICXCiPAuPni8i7I4zq3b9KP6pQ0nBJd1RkMww9ZurB cUqpz8X4GmxQV4XBGuPBPeuBbfDHNWsg/pcPUkGJ2N26GGNdjGXeniu2roD6jk/a0GD3 J77RzOjbFQGdtoPP2b1n7IAFV4we3wDu5e5wR+NKl17ULX5WXe02vdGVEGyU4y+a/Yv3 kQYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3xWLlOu9eSASoy6eXzt+azKM4r8qeRmNVdc/W+4eGpw=; b=m45XKrNssrWa9bomTEz68LHcgapZKj6tE06BqKlS0YDNEAgz/x9nDpzEmxBKrqHRRn Nca+mzk0I/KEHOm4GsmZuO1Maq6Wt0g8IOF+bMjvBJx0cWeati8TCf8T/6aOTz6DaK9u 6lFXy3ssSF6UdU/AC3jt7B3biRo7bIebddoOztlFNiMDZ57L7suT6Jqf9yOEK5MxxFyC QTH5sB0/cE/isjftWlwgzjVN9WlU57OUylfi4IhuePkq035axaUS1B/D/W6sP0AEbHSY MCioA1iF53KrIbRYqZwfndBQ49bSV5yLB7ZAXSjwSissmrJG/MKznWhUK/NpWRLDLIXT xIGA==
X-Gm-Message-State: AOAM530n1PiwGhqbb3w6NROBrZy4WIt5tb0kwu9tfkBnT3XeHcforK0Z h9kofHMQ0G+9vzE0H8ME/3cgY9zYamKKd+FCdOC8XsBXWQM=
X-Google-Smtp-Source: ABdhPJyeHHpN3I9J8t8Z80dHjFDx7i2qHbzqZXQhcl+p9sCAEKelbT8+fVyRfR9ABV/cXIKNmYqidBgAHLaPaSvYfm8=
X-Received: by 2002:a25:d015:: with SMTP id h21mr5330352ybg.234.1612974265684; Wed, 10 Feb 2021 08:24:25 -0800 (PST)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Wed, 10 Feb 2021 10:23:13 -0600
Message-ID: <CAMMTW_+77P3mPP+Txx9-78Z+GfG_mLWA5gCau+Bg+W2Gk8G70A@mail.gmail.com>
To: draft-ietf-alto-path-vector@ietf.org
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023571405bafdd6de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/6oYr0rjU9ZB_gG9muNLGrJknvPM>
Subject: [alto] Chair review of path-vector-13 (Part 2 of 2)
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: Wed, 10 Feb 2021 16:24:29 -0000

Dear Authors: This part concludes my chair review of path-vector, an
important ALTO extension.  Thank you for your work on this document.  I
hope the comments in this part and the first part help position the
document better.

Chair review from Section 7 to the end of the document.
Part 2 of 2.

Global comment: Please turn all "Content-Length: [TBD]" into
"Content-Length: XXX", where "XXX" is the computed content length.


- S7.1.3: When you first get into JSON object declarations, you should
point the reader to S8.2 of RFC7285, where the semantics related to the
syntax used to declare ALTO JSON objects is defined.  This will help new
implementers who
pick up this manuscript and need to understand where the declaration
syntax, and previously declared JSON ALTO objects, like ReqFilteredCostMap,

- S8.3: I think the ALTO response deserves a longer explanation here.  Let
me see if I understand correctly: the cost map returns two properties: NET1
and AGGR.  On NET1, the max reservable bandwidth is 50 Gb (or GB?), i.e.,
inside the NET1 abstraction of Figure 5, the max reservable bandwidth is
much higher than the link bandwidth.  For the AGGR (BTW, what does AGGR
stand for?  Minimum aggregate bandwidth?), the max reservable bandwidth is
10 Gbps, which is the bandwidth of L1.  Yes?  Please expand the explanation
in the document to be as explicit as you can.

Further, my suggestion would be to show the NET1 and AGGR from source to destination, because that will necessarily include
traversing two links, L1 and L2.  What would be the AGGR there?

- S9.2: I am not sure what the prescription here is.  Whatever it is, it
needs to be (a) explicit, and (b) stronger.  Current text says that this
document does not "specify" the use of path vector cost type with RFC
8189.  Why does it not specify this?  Is it because such integration is not
possible?  In which case, the document should say so.  Or is it because the
authors have not studied whether such integration makes sense and can be
supported in a backward compatible manner?  If so, well, say so.  Or is it
because such integration is not possible at all?  If so, say so.  This is a
protocol document, we need to be as unambiguous as possible.  (S9.3 is a
good example of drawing a line in the sand.)

- S10.2: Not sure why the MAY is normative here.  This paragraph should be
re-written in its entirety; it reads more like a draft set of notes than
something well thought out.

- S11, last paragraph: I am not sure what "intolerable increment of the
server-side storage" means here.  Isn't the issue more along the lines of
spending CPU cycles doing path computation rather than storage
requirements? Conflating "storage" here does not seem to be warranted, but
perhaps I am mistaken.  Please advise.

Further, the text says, "To avoid this risk, authenticity and authorization
of this ALTO service may need to be better protected." ==> I am unsure how
this helps.  The ALTO server has no means to authenticate the client, nor
does it have any means to know whether the client is authorized to send it
a request.  Consequently, the best it can do to protect itself is to
monitor client behaviour and stop accepting requests if the client
misbehaves (sends same requests frequently, sends requests with small
deltas frequently, or it can ask the client to solve some puzzle before
submitting a request, etc.).  But generally, this class of resource
exhaustion attacks are hard to defend against, and I am not sure that we
will come up with something that is definitely prescriptive here.  But we
should structure the discussion such that it appears that we have thought
of the issues here.


- S7.1.6, bullet item "The Unified Property Map part MUST also include
"Resource-Id" and "Content-Type" in its header." ==> Doesn't the
unified-props I-D already mandate this?  If so, why repeat it here?

- S9: I would suggest changing the title to "Compatibility with other ALTO

- S10.1, paragraph 3: I would suggest the following re-write for this

"In practice, developing a bespoke language for general-purpose boolean
tests can be a complex undertaking, and it is conceivable that there are
some existing implementations already (the authors have not done an
exhaustive search to determine whether there are such implementations).
One avenue to develop such a language may be to explore extending current
query languages like XQuery or JSONiq and integrating these with ALTO."

(Please provide references for XQuery and JSONiq.)


- S8.1: s/The example ALTO server provides/Assume that an ALTO server

- S9.1: s/conducting any incompatibility./incurring any incompatibility

- S11: s/requires additional considerations/requires additional scrutiny/

-S11: s/authenticity and authorization/authentication and authorization/

Thank you!