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

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>
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> 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>
> >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
> >> https://www.ietf.org/mailman/listinfo/alto
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >alto mailing list
> >alto@ietf.org
> >https://www.ietf.org/mailman/listinfo/alto
>
>