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