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

Hans Seidel <hseidel@benocs.com> Tue, 07 January 2020 16:26 UTC

Return-Path: <hseidel@benocs.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 2D9381200F3; Tue, 7 Jan 2020 08:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zFoy9dAZqGRf; Tue, 7 Jan 2020 08:26:32 -0800 (PST)
Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158AF1200E0; Tue, 7 Jan 2020 08:26:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 2346C650083; Tue, 7 Jan 2020 17:21:59 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at benocs.com
Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4WmiLTfCRR4; Tue, 7 Jan 2020 17:21:56 +0100 (CET)
Received: from [192.168.178.115] (unknown [192.168.3.10]) by mail.benocs.com (Postfix) with ESMTPSA id 1E0B0650067; Tue, 7 Jan 2020 17:21:56 +0100 (CET)
From: Hans Seidel <hseidel@benocs.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>, Ingmar Poese <ingmar@inet.tu-berlin.de>
Cc: draft-ietf-alto-incr-update-sse@ietf.org, IETF ALTO <alto@ietf.org>
References: <CAMMTW_KOHEfE7AojeviUdUVqmDLmJQ97+hUeoMKj1A0wwAzY6w@mail.gmail.com> <CAEDarXKPD7x35GRFiYgMy2jnq5NsfYumDR4K5DbQz_AhJHKeig@mail.gmail.com> <2a1f25f3-65ca-4343-a0a5-0d387840ff19@inet.tu-berlin.de> <CAMMTW_JhJw65fczkEVBaQ3fRfn+JzNbZQWjcfP1eavOWHgRn3w@mail.gmail.com>
Message-ID: <1704dd78-aa52-7235-1d25-25648ab776ab@benocs.com>
Date: Tue, 7 Jan 2020 17:26:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CAMMTW_JhJw65fczkEVBaQ3fRfn+JzNbZQWjcfP1eavOWHgRn3w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6EAC39E4ED61C07FEDCFBC42"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/9IOwXNAxqKp_CwKUPsu54W4lB08>
Subject: Re: [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: Tue, 07 Jan 2020 16:26:36 -0000

Hi Vijay,

let me answer this question for Ingmar. Currently implemented is the 
JSON merge patch feature. JSON patch is on our roadmap. We aim for a 
release that is fully compatible with the latest draft prior to the 
Vancouver IETF which I also plan to attend. Once the RFC is published, 
we are going to use SSE in production with our partners.

If you or somebody on the list has an ALTO implementation and is 
interested in running tests, feel free to contact us.

If you like to know more, feel free to ask. We also happily give further 
insights in our SSE implementation, or our ALTO implementation in 
general in Vancouver. If you or the list is interested in specific 
parts, please let us know and we prepare some slides for Vancouver.

Best,
Hans

On 06.01.20 22:35, Vijay Gurbani wrote:
> Dear Ingmar: This is great information, thanks.
> Did you implement both JSON patch and JSON merge patch?
> Thanks,
> - vijay
>
> On Mon, Jan 6, 2020 at 2:50 PM Ingmar Poese <ingmar@inet.tu-berlin.de 
> <mailto:ingmar@inet.tu-berlin.de>> wrote:
>
>     Hi Danny,
>
>     We (BENOCS) have implemented the Alto SSE, but are lacking a
>     partner to speak it to in production scale.
>
>     In our testing environment it seems to work fine (even with
>     production data).
>
>     I was unable to attend Singapore, but will be available in
>     vancouver (and possibly madrid) to chat/present the research.
>
>     Best,
>     Ingmar
>
>     Am 6. Jan. 2020, 19:56, um 19:56, Danny Alex Lachos Perez
>     <dlachosper@gmail.com <mailto:dlachosper@gmail.com>> schrieb:
>     >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
>     >
>     >[0]
>     >https://mailarchive.ietf.org/arch/msg/alto/h7QJRu47NbTvfcnW2fveFqCBRdw
>     >
>     >On Mon, Jan 6, 2020 at 4:32 PM Vijay Gurbani
>     <vijay.gurbani@gmail.com <mailto:vijay.gurbani@gmail.com>>
>     >wrote:
>     >
>     >> 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?
>     >>
>     >> MAJOR
>     >> -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?
>     >>
>     >> MINOR
>     >> 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.)
>     >>
>     >> NITS
>     >> -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
>     >> _______________________________________________
>     >> alto mailing list
>     >> alto@ietf.org <mailto:alto@ietf.org>
>     >> https://www.ietf.org/mailman/listinfo/alto
>     >>
>     >
>     >
>     >------------------------------------------------------------------------
>     >
>     >_______________________________________________
>     >alto mailing list
>     >alto@ietf.org <mailto:alto@ietf.org>
>     >https://www.ietf.org/mailman/listinfo/alto
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto