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

From: Vijay Gurbani <[email-masked]>
Date: Mon, 6 Jan 2020 12:33:38 -0600

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

---

From: Danny Alex Lachos Perez <[email-masked]>
Date: Mon, 6 Jan 2020 16:55:57 -0200

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 <[email-masked]>
wrote:

> (i.e., TLS).  Perhaps you meant “...., but uses a different HTTP method,
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 6 Jan 2020 15:35:28 -0600

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 <[email-masked]>
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 <
> [email-masked]> schrieb:
> >Hello Vijay,
> >Happy new year!!!
> >
> >[0]
> >https://mailarchive.ietf.org/arch/msg/alto/h7QJRu47NbTvfcnW2fveFqCBRdw
> >
> >> [1]
> >https://mailarchive.ietf.org/arch/msg/alto/C9_tS44bz7kq84Z3cpZZkMeUDFc
> >>
> >> Thank you.
> >>
> >> - vijay
> >------------------------------------------------------------------------
> >

---

From: Hans Seidel <[email-masked]>
Date: Tue, 7 Jan 2020 17:26:26 +0100

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:
> On Mon, Jan 6, 2020 at 2:50 PM Ingmar Poese <[email-masked] 
> <mailto:[email-masked]>> 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
>     <[email-masked] <mailto:[email-masked]>> schrieb:
>     >Hello Vijay,
>     >Happy new year!!!
>     >
>     >On Mon, Jan 6, 2020 at 4:32 PM Vijay Gurbani
>     <[email-masked] <mailto:[email-masked]>>
>     >wrote:
>     >
>     >> All: Happy new year.
>     >>
>     >> In preparation of moving alto-incr-update-sse ahead, I have
>     performed
>     >a
>     >> and considers various design tradeoffs.  This is fairly mature
>     work,
>     >and we
>     >> the Stream Control Transmission Protocol (SCTP) service, a
>     transport
>     >layer
>     >> S4: The phrase “Using existing techniques wherever possible,”
>     implies
>     >that
>     >> you have used other, perhaps new techniques at other places. 
>     Is that
>     >the
>     >> -S4.2.1, page 10: s/, and (3) assigns a new tag to the network
>     map:/,
>     >(3)
>     >> should monotonically increase from this starting value.  (I
>     will let
>     >the
>     >> [email-masked] <mailto:[email-masked]>
>     >[email-masked] <mailto:[email-masked]>

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 7 Jan 2020 10:35:06 -0600

Dear Hans: Thank you for your email.  At this point, I am interested in
getting as much information about the implementation of the Internet-Draft
as possible in preparation for moving the work ahead in the WG.  Certainly,
I will be happy to allocate you some agenda time in Vancouver to document
any lessons learned on implementing alto-sse.  If you are interested,
please let me know.

If anyone else on the list has any implementation of alto-sse, please let
me know as well.

Thanks,
- vijay

On Tue, Jan 7, 2020 at 10:26 AM Hans Seidel <[email-masked]> wrote:

> 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.
>
> 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.
>

---

From: Hans Seidel <[email-masked]>
Date: Wed, 8 Jan 2020 14:06:02 +0100

Hi Vijay,

perfect. I am looking forward to present in Vancouver. Among 
implementation insights, we also happily share information about lessons 
learned and rolling out ALTO with partners.

I will file an agenda request for the Vancouver session once asked for 
on the list.

Thanks,
Hans

On 07.01.20 17:35, Vijay Gurbani wrote:
> Dear Hans: Thank you for your email.  At this point, I am interested 
> in getting as much information about the implementation of the 
> Internet-Draft as possible in preparation for moving the work ahead in 
> the WG.  Certainly, I will be happy to allocate you some agenda time 
> in Vancouver to document any lessons learned on implementing 
> alto-sse.  If you are interested, please let me know.
>
> If anyone else on the list has any implementation of alto-sse, please 
> let me know as well.
>
> Thanks,
> - vijay
>
> On Tue, Jan 7, 2020 at 10:26 AM Hans Seidel <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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 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.
>

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 8 Jan 2020 07:32:13 -0600

Very well, please do file a request for agenda items once the email goes
out for Vancouver. Thanks.

On Wed, Jan 8, 2020, 7:06 AM Hans Seidel <[email-masked]> wrote:

> I will file an agenda request for the Vancouver session once asked for on
> the list.
>
> Thanks,
> Hans