Sebastian,

Comments in-line.

        - Wendy

On 09/06/2016, 14:15, "Sebastian Kiesel" <[email protected]> wrote:

>Hi Wendy,
>
>please see below...
>
>On Mon, Sep 05, 2016 at 04:16:37PM -0400, Wendy Roome wrote:
>> Sebastian,
>> 
>> Thanks reviewing the document. And thanks for keeping us honest! I will
>> address your major comment first, and then the minor ones in a later
>>post.
>> 
>> ***** SSE vs HTTP/22 Server Push:
>> 
>> Yes, by the time this is published, HTTP/2 support will be more common.
>> Although not universal. For example, Java still does not support HTTP/2
>>as
>> a client, and will not until sometime in 2017.
>> 
>> But comparing the two approaches, the primary advantage of HTTP/2 is
>>that
>> it is officially blessed by the IETF. SSE will still be around for a
>>long
>> time.
>> 
>> ...
>
>This all sounds plausible to me.  So, no need to revise your decisions,
>but maybe add some words to the draft.


In progress. (Great minds think alike! :-))


>> ***** Could this be made optional? As in, give me the diff for the ..
>>map
>> since tag ...
>> 
>> Alas, that only works for maps with tags. Eg, that would work with
>>Network
>> Maps. But it would not work for Cost Maps, or Endpoint Cost requests, or
>> Endpoint Property requests, etc.
>
>Could we use this draft to introduce a tag to the cost map, for the
>purpose of requesting diffs?
>
>Then, the mechanism would work with Network Map and Cost Map.
>These two are probably the most important targets for periodic
>incremental updates.


Tagging cost maps might be a good idea, but there are some possible
problems, and I think that needs a separate draft. Do you want to do
submit one? Or formally solicit comments?


>
>> ***** I am not really convinced that in every scenario sending a keep
>> alive message every 15 seconds is more efficient than the client asking
>> for updates in similar time intervals.
>> 
>> Keep-alives are much more efficient, because they just send 10 more
>>bytes
>> on an existing TCP connection. Eg, one message. A request requires
>>setting
>> up a new TCP connection. That takes several messages, involved
>>allocating
>> new ports, etc. It is a lot more overhead on both the client and the
>> server.
>
>You are right, opening a new TCP connection every 15 seconds is less
>efficient than sending 10 bytes every 15 seconds over an existing
>connection,  But there may be a break-even point ... What if I want the
>updates only every 120 seconds?  Is one new TCP connection more
>effort than 8 keep-alives? Or 16?
>
>Maybe it is not worth the effort of changing the spec and adding some
>explanation is the better approach, but the current document leaves some
>feeling of strange asymmetry in me - one mechanism optional, the other
>one mandatory without a good explanation why.
>
>Sebastian


The keep-alive time is in the SSE specification:

Legacy proxy servers are known to, in certain cases, drop HTTP connections
after a short timeout. To protect against such proxy servers, authors can
include a comment line (one starting with a ':' character) every 15
seconds or so.

 


_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to