[alto] Chair review of draft-ietf-alto-incr-update-sse-17

Vijay Gurbani <vijay.gurbani@gmail.com> Mon, 06 January 2020 18:32 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 028121200EB; Mon, 6 Jan 2020 10:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 y7BqgrI9k59h; Mon, 6 Jan 2020 10:32:08 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 6BEC712010C; Mon, 6 Jan 2020 10:32:08 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id cy15so48240391edb.4; Mon, 06 Jan 2020 10:32:08 -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; bh=1i/Bqnne/BHLWpFRYJ506M1tNVj1BJXnJvpHgtaKioU=; b=Lh6XRb2ChL7uOiaa8t8Ah5C/zHg8JlL+JOYKd2DVPoYGuwlvrY6qLzWQXEQRTbeVik lU4uRimoPD9pGAhBFvfX0mi/4chg58Jn8dhyNXh3iSlVNRaMhSWqBOp9A5SGC4tEfFcc ohbibY6YIKtbSzr8Bv79rEpqn9eFTjYmmuq7/lTUjmVDzQc/jr2ZfddUtenTkZLtQqD2 YPZBtvhf9mr1AFO++iAEFh8dAltcNVzZNRnKM+40EqHkGgp+147QypeipDPB/SY4JUYv q3czfhQCpwkIyZV+exZiewdkWkFJgKyKfmEFsq/DHF7fxTMVlI8xk/bXT5wy3mK73h1W oozg==
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; bh=1i/Bqnne/BHLWpFRYJ506M1tNVj1BJXnJvpHgtaKioU=; b=s1JHMpoReRIM9OxoJXFVgG337v7SS5hBwAG5v9AH7UUDbDb/laeGThWK2rHgnnWdFU 6IiLyfKpWNXjqa6V0esFid9hylwj5spd5T4pdYUjdCQYQ3bR6MO5/fBcZeymM/RGxRpN lnvFhRFIVYhZa57ApFrqV+hIpuLlHpKUjRy1hGE47MXAw1MLAwA2NrPP9G/ze9P0B89v 7q6wj1QAVWiMq7H36YyuHdqdtOLClsTtVXr6Shr6mFBQn8AAUEjvPoTmIhL3qHM6k2fz BfS5U9hXSM/zCicLcINQ9Atdd1Qdv8oKEG65bHOZX7YIT7foRKwDT7z8++EIY0yI5qKD Oubw==
X-Gm-Message-State: APjAAAUz2ffHLat6upc7sZFbgrySuYdr0mfKMOtBZPya4nK0vAxt5/31 x0mXkZ1/oTFyK6nLdjcNJVg/SSj0CusD18N6M4K3hHOm
X-Google-Smtp-Source: APXvYqyw1UXwigKy/7lKtBig9Ebm6/0kk03rczvaZ7Ee54C0+oNpEBjkfScNLY573JpLcWBgB0pYYYyZd+G5p1F3Ioo=
X-Received: by 2002:a17:906:a14:: with SMTP id w20mr109486453ejf.274.1578335526280; Mon, 06 Jan 2020 10:32:06 -0800 (PST)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Mon, 6 Jan 2020 12:33:38 -0600
Message-ID: <CAMMTW_KOHEfE7AojeviUdUVqmDLmJQ97+hUeoMKj1A0wwAzY6w@mail.gmail.com>
To: draft-ietf-alto-incr-update-sse@ietf.org, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000616281059b7ce089"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/-6AhxLa8o409o2k2gv5fXd9-6g4>
Subject: [alto] Chair review of draft-ietf-alto-incr-update-sse-17
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: Mon, 06 Jan 2020 18:32:11 -0000

All: Happy new year.

In preparation of moving alto-incr-update-sse ahead, I have performed a
chair review of the work.  Overall, the document is well written, mature,
and considers various design tradeoffs.  This is fairly mature work, and we
should move it out of the WG following the resolution to the review below
and an additional review by Jensen Zhang [1].

--- Begin chair review

I am curious --- are there any known implementations of alto-sse?

-S10.1: This is an important discussion.  However, this discussion is
written primarily from a viewpoint of an ALTO client, but if I understand
it correctly, it should be written from the viewpoint of an ALTO stream
server since it is the stream server that is generating the event since
that is the source that should be told to behave conservatively.  Should
this section be re-written to exhort the stream server to send out full
cost maps in chunked format, where each chunk is at most 2,000 octets?
That way, the clients are not overwhelmed.  Thoughts?

S3: It is rather unfortunate that one of the services is named “Stream
Control Service” as this may be conflated by the uninitiated reader with
the Stream Control Transmission Protocol (SCTP) service, a transport layer
protocol.  Clearly, that is not the intent here.  However, I am loathe to
suggest a new naming scheme this late in the document publication phase, so
perhaps the best we can do now is to add a note explicitly disassociating
Stream Control Service of ALTO from SCTP.  Perhaps something like: s/from
the update stream./from the update stream. (Note that the Stream Control
Service in ALTO has no association with the similarly named Stream Control
Transmission Protocol [RFC4960].)/

S4: The phrase “Using existing techniques wherever possible,” implies that
you have used other, perhaps new techniques at other places.  Is that the
case?  If so, please enumerate the new techniques; if not, perhaps reword
as s/Using existing techniques wherever possible,/Using existing

-S4.2.1: “This document adopts the JSON merge patch message format to
encode incremental changes, but uses a different transport mechanism.” ==>
Not sure how to interpret this.  Since alto-sse uses the HTTP PATCH method
to affect incremental updates, it uses the same “transport mechanism”
(i.e., TLS).  Perhaps you meant “..., but uses a different HTTP method,
i.e., it uses POST instead of PATCH (details in Section 5).”?

-S4.2.1, page 10: s/, and (3) assigns a new tag to the network map:/, (3)
leaves “PID3” unmodified, and (4) assigns a new tag to the network map:/

-S6.1: Is there some magic about the numbers “1” and “2” assigned to
substream IDs?  In other words, must substream IDs begin with 1 and
monotonically increase?  If so, state that.  If not, then state that
substream IDs must begin with a random number between [1, 10] and
monotonically increase from there on for each new substream.  That is, if
the first substream ID is 6, then subsequent substream IDs from the client
should monotonically increase from this starting value.  (I will let the
protocol designers come up with the exact text to impart this.)

-S5, page 16: s/this design allows/this document allows/
(Overworked use of “design”: “...flexible protocol design, this design…”).

-S10.1: s/single character array./character array./

-S10.1: s/client computer/client/

--- End of chair review

Additionally, the work has also been reviewed by Jensen [1].

Authors, please attend to the comments indicated in this review and
Jensen's review and release a new version in order to move the work forward.

[1] https://mailarchive.ietf.org/arch/msg/alto/C9_tS44bz7kq84Z3cpZZkMeUDFc

Thank you.

- vijay