[alto] ALTO Meeting Info for Jan. 08, 2020

[Danny Alex Lachos Perez]

Dear all,

Just a friendly reminder that we will have our weekly meeting this
Wednesday (*Jan-08*) at *9:30 am US ET*.

Agenda*:

   - Updates on existing WG documents
   - Discuss WG rechartering
   - Plan for next side meeting/workshop

*If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/j/8423318713

Best regards,

Danny Lachos
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Vijay Gurbani]

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

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

[Hans Seidel]

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 > 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
mailto: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
mailto: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 diff