Re: [Anima-signaling] GRASP issue 51: Flooded objectives

So, here is where my head is now on flooding.

1. We specify that the source address is cached with the flooded objective, and that
multiple copies are kept if there are multiple sources.
2. To cover the common case, if a regular ASA calls synchronize(obj) it will
by default get back the first entry in the flood cache, and if there is nothing
in the flood cache, GRASP will discover and synchronize the objective.
3. To cover the case where we want multiple flooded values, we'll add a function
to the API called something like get_flood(obj) which will return a list
of versions of the objective, each tagged with its source address.

Text? I have put some words into my working version of the GRASP spec.
I will push the latest XML to GitHub shortly.

Running code? Yes, I've coded all that in my prototype and tested all the code
paths. (I don't intend to publish that code until we get a -07 draft out.)

In terms of freshness, here's some text:

   If the value of an objective has time-sensitive properties such as a
   defined lifetime, a defined expiry time, or a defined refresh rate,
   these SHOULD be expressed as part of the definition of the objective
   itself; they are not foreseen in the GRASP protocol.  For example, an
   objective that is flooded using Flood Synchronization might include a
   parameter specifying its expiry time as a UTC string.

Regards
   Brian

On 01/08/2016 20:55, Toerless Eckert wrote:
> Inline.
> 
> On Mon, Aug 01, 2016 at 08:47:22AM +1200, Brian E Carpenter wrote:
>> Hi,
>>
>> Prior to raising this on the WG list, I'd like feedback from the design team.
>>
>> Following side discussion with the bootstrap and ACP teams in Berlin, there
>> is a new issue about flooded objectives (not really about the Flood message
>> itself). It has two aspects:
>>
>> 51.1 Should flooded objectives have a time-to-live before they are deleted from
>> the flood cache? I think the answer is no, because in any case the source can repeat
>> the Flood message if the value changes. If anybody sees a use case for a TTL,
>> please explain it.
> 
> We discussed in Berlin methods to discover sources that went away:
> 
> a) IMHO, we do not want to send rapid updates from sources to discover quickly when
>    they die because of the absence of those announcements. (aka: no fast aliveness).
> b) IMHO we do not want to work out the details of the GRASP infra quickly detecting
>    when a sources goes away and flood that information (no IGP like fast source revocation).
> c) I suggestested that GRASP clients could help:
>    - GRASP thinks source is alive (long or no TTL)
>    - GRASP API client tries to connect to objective, and fails
>    - GRASP API client tells GRASP "objective seems dead".
>    - GRASP removes objective source from cache
>    - When GRASP receives another flood message from objective source,
>      it repopulates cache and tells client.
> 
> With c) in mind, we might not need a TTL, but I am not aware of existing service
> announcement mechanisms that tried to rely on this "c)" approach, so i am a bit
> weary to solely rely on it:
> 
> When there is a network disconnect between objective and client, the client would not
> be able to reach the objective and the objective would be declared dead. Aka: If we
> do "c)", we do need to periodically flood from the objective source the announcement
> to recover from this situation. The periodicity should be determined by the source
> itself. But it would be good if the source also announced this periodicity.
> 
> Aka: I would suggest that intead of TTL, the source could simply announce the periodicity
> of it's announcements (in seconds). Default 30 seconds.
> 
> If a client does not perform "c)", then it can use the periodicity value to
> calculate when it can declare the source dead - eg: after three periods non-receipt
> of a message.
> 
> There is also a fundamental limitation with "c)", and that is when the announcer
> is not tightly coupled with GRASP:
>    - GRASP could announce the objective, but the process providing the objective
>      could be running on a different system and could have died. Or maybe this is
>      even possible on the same system.
>    - Client connecting to the objective  would declare it dead to GRASP, but
>      GRASP would continue to see announcement from the source.
> 
> Ideally, we would not have this case, aka: GRASP API should always know when
> the actual source of the objective is really alive. But i am not sure if it's possible
> to always guarantee this. So it would be good to have in the flooded objective
> some indiciation that the GRASP announcement is not coupled to the objective aliveness
> itself.
> 
> I am extrapolating this case from what we do with mDNS: Most services today do
> not couple to mDNS via API. Instead when we use something like Avahi, then there
> are Avahi config-files that describe the services running on the same system (or
> on another system). Which of course does not guarantee that each of those services
> is actually working fine. So i't seasy to announce services when they do have
> problems (eg: can't start, fail, ...).
> 
> Aka: objective parameter "GraspObjectiveCoupled" (or come up with a better name).
> If true, it means that the GraspSource and Objective Owner feel that it's safe
> to do c) on the client side to discover death of the service, and false means it is not.
> 
> 
>> 51.2 We do have a potential use case where more than one source floods the same
>> objective, and the recipient ASAs need to distinguish the results. That use case
>> is when there are multiple bootstrap proxies advertising on the same LAN, and the
>> joining nodes (pledges) can choose which one to try. I'm sure there will be others.
> 
> The most important one being multiple registrars announcing the registrar service,
> and the bootstrap proxies want to discover them, and then choose the best one based
> on network distance (aka: remaining loop count).
> 
>> My proposal is to specify that a node receiving a Flood message will cache
>> the received objective plus its source locator (which is already in the message
>> for other reasons). We'll also have to upgrade the API so that the recipient
>> ASA can get multiple flooded answers.
> 
> Yes.
> 
> Thanks!
>     Toerless
>>
>> Comments?
>>
>> Regards
>>    Brian
>>
>> _______________________________________________
>> Anima-signaling mailing list
>> Anima-signaling@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima-signaling
> 