Subject: Re: [alto] New Incremental Update draft

From: Hans Seidel <[email-masked]>
Date: Thu, 1 Oct 2015 16:45:54 +0200

Wendy, Richard,

great work.

One question that came up while reading:

1. Is it allowed to use "start-updates" and "stop-updates" in one HTTP 
request? I found nothing specific that neither supports nor contradicts 
that.
     Intuitively, I would say no, it is not allowed to have both in one 
request but I am not entirely convinced.

Hans

On 29.09.2015 17:48, Y. Richard Yang wrote:
> To add to the info by Wendy, we want the list to know that following 
> the spirit of running code, the team of ALTO@ODL is also starting to 
> do the implementation of SSE. If you have interest, please let us know.
>
> Richard
>
> On Tuesday, September 29, 2015, Wendy Roome 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     Richard & I updated the incremental update draft:
>
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dalto-2Dincr-2Dupdate-2Dsse-2D01.txt&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=slfp3TRkN394bivOqmD24pjhcrOGj7qyTMNTJYVSBIQ&e=
>
>
>     The primary change was I added a mechanism to let a client tell
>     the server
>     to close the stream. This shuts the stream down quickly & cleanly. The
>     client can just close the stream, of course, but that can take a
>     while for
>     the server to detect, and it looks like an I/O error.
>
>     Section 3 summarizes the other changes, most of which are
>     clarifications.
>
>     The Alcatel-Lucent public server,
>     https://urldefense.proofpoint.com/v2/url?u=http-3A__alto.alcatel-2Dlucent.com-3A8000_directory&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=TWWzEEQgxCMd17ICx7chi8-DKni-0kcxNL1SVxaxFAo&e=
>     , provides an Update Stream
>     resource as described in the -01 draft. The server updates the default
>     network map every 60 minutes (approximately), and every 5 minutes it
>     updates a few routingcost values for the default network map and a few
>     property values.
>
>     Note that because that server handles the interop test network, the
>     updates just replace the current values with the same values. But that
>     counts as an update in my server, so it exercises all of the update
>     plumbing.
>
>     One wart: when you create a new Update Stream, the initial response is
>     delayed for 50 seconds. I don't know what causes that delay, but
>     it only
>     happens on this particular server, and it is very repeatable. That
>     server
>     is in our corporate DMZ, so it may be a result of the firewall, or
>     routing, or some other security feature. In any case, once you get
>     over
>     the initial 50 second delay, subsequent updates arrive quickly.
>
>     Oh yes, I could not find an SSE library, so I had to write my own.
>     I would
>     greatly appreciate it if other people could try it and verify that
>     my SSE
>     implementation meets the specification.
>
>             - Wendy Roome
>
>
>
>     _______________________________________________
>     alto mailing list
>     [email-masked] <javascript:;>
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=DOFJXxQJVz_ERNgTqwtat30JEEXyPxEyMPYBPvV8rqY&s=wi48BWjWERAAmlsmH5X4thluWqXWCcHVPBQOAk5lL_I&e=
>
>
>
> -- 
> Richard
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Wendy Roome <[email-masked]>
Date: Thu, 01 Oct 2015 11:53:40 -0400

Hans,

Thanks for pointing that out!  First, I assumed they were exclusive: a
request can have start-updates or stop-updates, but not both. But the draft
does not say that. My implementation does not support both in one request,
but does not return an error if a request does. (My server just ignores the
stop-updates field. My culpa!)

But I just realized there is a use for having both in one request. Suppose a
client wants to stop a previous update-stream, and replace it with a new
stream. Combining both in the same request is more efficient. On the other
hand, is that going to happen often enough to matter?

To complicate things, a request with start-updates, stream-id and
stop-updates is ambiguous. The stop-updates part is clear. The ambiguity is
for the new resources in start-updates. Should the server return updates for
those on the new tcp connection? Or should the server add the start-updates
resources to the *other* stream - - the one with the stream-id?

I see several ways to fix that:

1. Say that start-updates & stop-updates are mutually exclusive. That is, a
request has start-updates, or stop-updates and stream-id, but no other
combination. And say the server must return an error if the client violates
that rule.

2. Allow both in one request. But then we have to decide whether the
start-updates resources are to be added to the existing stream, or to be
returned in a new stream.

3. Define two separate requests: start-new-update-stream and
modify-existing-update-stream. They would have different parameter types,
and hence different accepts media-types. That is unambiguous, and is very
general, and would allow a client to add resources to an existing update
stream. But that approach is more complicated, and I do not know if the
extra complication is worth it.

What do the rest of you think?  My vote is for #1, just to keep it simple.

- Wendy Roome

From:  Hans Seidel <[email-masked]>
Date:  Thu, October 1, 2015 at 10:45
To:  "Y. Richard Yang" <[email-masked]>, Wendy Roome
<[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [alto] New Incremental Update draft

Wendy, Richard,

great work.

Hans