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 <[email protected]
<mailto:[email protected]>> 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 protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
>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
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/alto
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>alto mailing list
>[email protected] <mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
