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 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 < > dlachos...@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 > >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 com
Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17
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 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
[alto] Chair review of draft-ietf-alto-incr-update-sse-17
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
