Subject: [alto] Incremental Update/SSE Key Design Issue 3: updates for dependent resources

From: Xiao SHI <[email-masked]>
Date: Thu, 23 Oct 2014 07:15:18 -0400

Hi guys,

I have some questions on the procedures to update dependent resources.

Suppose the network map M updates from v1 to v2; in the meantime, four cost
maps C1 C2 C3 and C4 that depends on said network map each have their own
update and they switched dependency from networkmap v1 to networkmap v2.
What is the process of updating these 5 resources/applying these updates if
they become available at different times?

Our main goal is for the update to happen as soon as possible and for all
the involved resources to remain as available as possible.

Theoretically, similar to what a compiler/linker does, since the cost maps
depend on M, we should update M first to v2, then update the depending
resources. The issue with this approach is that until all cost maps are
updated, their look-ups are potentially not usable as their dependent
network map has changed.

If we hold off applying the update on network map, we must wait for all
depending resources to complete. That's not ideal either.

Should the clients store multiple versions of resources then? How would
this work? Are there examples from other implementations that handle
similar questions (e.g. compilers, git internals, software package updates,
etc.)?

Thoughts?

Cheers,
Xiao

---

From: Wendy Roome <[email-masked]>
Date: Thu, 23 Oct 2014 11:07:26 -0400

If the server sends all 6 of those updates on the same stream, it's a
non-issue. The client applies the updates in the order in which they arrive.

Of course, the server must ensure that a cost-map update always applies to
the most recently sent network map update.

Eg, if updates C1 & C2 depend on network map update M1, and updates C3 & C4
depend on M2, then the server sends:

        M1  C1  C2  M2  C3  C4

When a client gets a network map update like M1, the client could apply the
update and mark the associated cost map as ³temporarily invalid². The client
changes that to ³valid² when next cost-map update arrives. Hopefully the
server will send that very quickly. While a cost-map is temporarily invalid,
the client must defer any accesses to that cost-map.

Alternatively, the client could save a network map update in a buffer until
the associated cost map updates arrive,
and then apply all those updates atomically.

In any case, there is no need for a client to keep multiple versions.

- Wendy

From:  Xiao SHI <[email-masked]>
Date:  Thu, October 23, 2014 at 07:15
To:  IETF ALTO <[email-masked]>
Cc:  Wendy Roome <[email-masked]>, "Y. Richard Yang"
<[email-masked]>
Subject:  Incremental Update/SSE Key Design Issue 3: updates for dependent
resources

Hi guys,

Should the clients store multiple versions of resources then? How would this
work? Are there examples from other implementations that handle similar
questions (e.g. compilers, git internals, software package updates, etc.)?

Thoughts?

Cheers,
Xiao