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

Danny Alex Lachos Perez <> Mon, 06 January 2020 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CF87120105; Mon, 6 Jan 2020 10:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wnmVOlaPGck6; Mon, 6 Jan 2020 10:56:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AEFF120077; Mon, 6 Jan 2020 10:56:10 -0800 (PST)
Received: by with SMTP id h13so12757905vkn.10; Mon, 06 Jan 2020 10:56:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=40ZSitLXM9r5BcZOXD3htkMLoSPSs0pJQbRjhCB12NE=; b=oj31VGKZ1S8lPBQu6E8K0iDrM89ZKWd/9U2MfRtab9qAdOr0v03VCIzwZwnnruZXjh Qo2iaQDZWiozRONObuAJNDywO9pOheZsNNrTjBCXV5VUC96BiNw3eEl1wc532DuAwVDI a3rQbXnN/h7NDdcC8LhuDu+y/gyNhH3lnA02g/hYFlltos04Ylsr/fBg5cz6920HDpmK gsXugt8z7Vhb9v/Y34IjjI+V2Erb8TMps3g9Ef51D+kPqD2nVyfIcURw4C32Drh128/o s3sw6WChguK0VkZymCpZyEEb05Cun4UHWEXB1FljKxkYe4rlzVnV/wlTUpbj1+dO/pWd 6Wqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=40ZSitLXM9r5BcZOXD3htkMLoSPSs0pJQbRjhCB12NE=; b=OtCGm6EMn3dXuFFFYu5qJ5kHAQbwAzzZWZ9I2wEWlIaJnJWfMDS7Hvky7QTyreRaV7 3ZYxtPjjKnu5sqYaml0v3P3Rfo2hj0l5hNmGDY9RnPONOPvTpYElQrrS3DC6FxxSkFqc ilASFUi+HoH+pHxLbQYJZaOL27vOYALHLqSFfw9TDfM1MkHFiqzpwSBk6i81DdwJu2yN 6IhzCA4yvMCujHJPuP+GCf+MlkUAegr/sZOlLJ+k2FqSZdYX1J5YbQV5PCSx8SLXBB3Y FrO86c+cgiUTTZw7n+wI0EJUgb0fNrb34UNztb6o0tlOn9qQB9cTr4E4xC9tHO6pPKSx uKvA==
X-Gm-Message-State: APjAAAW7A6FUSFK9bbaOtWYkZ2HxqzqOcaVRhwvFBvBcAqTGX6bK0567 3fNItNo0z6JGuCehWgBzJQm3vMoHAJplr5ysuRo=
X-Google-Smtp-Source: APXvYqw6YLuHFFhMmjbzHBFwOeti99uSeo5GpL0FgIzq/KD3TEXRpOoklw6733WPHV4vanlZkrsHiPqWr4gPhM+dHDA=
X-Received: by 2002:a1f:18cf:: with SMTP id 198mr58379319vky.61.1578336969074; Mon, 06 Jan 2020 10:56:09 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Danny Alex Lachos Perez <>
Date: Mon, 6 Jan 2020 16:55:57 -0200
Message-ID: <>
To: Vijay Gurbani <>
Content-Type: multipart/alternative; boundary="00000000000060ac83059b7d36e8"
Archived-At: <>
Subject: Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jan 2020 18:56:13 -0000

Hello Vijay,
Happy new year!!!

Just a quick comment to your question about implementations of ALTO-SSE

There is a related work "Steering Hyper-Giants’ Traffic at Scale" [0] where
ALTO is used as a northbound interface in a *real operational environment
at scale*.
The authors mention the SSE extension (but I am not sure if this extension
was also tested).

Best regards,

Danny Lachos


On Mon, Jan 6, 2020 at 4:32 PM Vijay Gurbani <>

> 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
> techniques,/
> -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]
> Thank you.
> - vijay
> _______________________________________________
> alto mailing list