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

[Brian E Carpenter <[e-mail]>]

Design team,

So, assuming that silence from the WG means assent, I will propose
a change to the Flood message format that adds an optional TTL field
and an optional locator field (which can be the same format as
in a Discovery Response).

While I'm there, should I add an optional TTL field to the Discovery
Response too? It would make the Flood and Discovery Response messages
essentially identical, and if it's optional there will be no
unnecessary overhead.

Regards
   Brian


On 12/08/2016 09:15, Brian E Carpenter wrote:
> Hi WG,
> 
> This rather long message expands on GRASP issue 51, which is summarised as:
> 
> 51.  Should flooded objectives have a time-to-live before they are
>      deleted from the flood cache?  And should they be tagged in the
>      cache with their source locator?
> 
> This has led to a complicated discussion in the signaling design time (mainly
> between me and Toerless) and we would like feedback from the WG before taking
> any firm decisions.
> 
> Breaking it down into separate issues:
> 
> 51.1 Should flooded objectives have a time-to-live before they are deleted from
> the flood cache?
> 
> Cutting a complex discussion short, it seems that we will surely have use cases
> where a time-to-live is needed. It might be infinity, of course, but we might also
> want to be sure that a flooded objective vanishes after 30 seconds. To do that, we
> need to add a TTL field.
> 
> Q1: Does the WG agree to add a TTL to the Flood message?
> 
> 51.2 We do have at least one 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 more than one Registrar or Proxy announces its availability
> via a flooded objective, so that joining nodes don't need to send an insecure
> Discovery message during bootstrap.) So the flood cache needs to record the
> source of the flooded objective.
> 
> 51.3 That leads to another complication. Suppose that more than one ASA in a given
> node floods the same objective.
> 
> Side issue: I (Brian) had been working on the assumption that only one ASA in
> a given node can manage a given objective. "Manage" means being willing to act as
> a negotiation responder, a synchronization responder, or as a source of flooding.
> But in fact, although there might be a reason for that limitation in a particular
> use case, GRASP as a protocol could perfectly well handle several ASAs managing
> the same objective. [My prototype implementation cannot really do so, but that's
> an implementation choice.]
> 
> Return from side issue: If more than one ASA in the same node floods the same
> objective, recording the source (as mentioned under 51.2) is not enough. We would
> need to separate multiple instances from the same source node. There is a use
> case for this too: if we want to make a soft changeover from version N to version N+1
> of a given ASA, where version N is not switched off until all current sessions
> end, but all new sessions will involve version N+1.
> 
> This will not cause any protocol changes for GRASP discovery (which already
> returns a locator as a 3-tuple {IP address, protocol, port}. Therefore,
> it won't cause any changes for synchronization or negotiation, which are
> based on discovery results.
> 
> But it does mean that to distinguish flooded objectives from each other, we will
> need to tag them too with a 3-tuple {IP address, protocol, port}.
> 
> Q2: Does the WG agree to add a locator 3-tuple to the Flood message?
> 
> When considering these additions to Flood messages, which add a few bytes
> of overhead, please consider that for most use cases, the frequency of
> flooding would be quite low.
> 
> Regards
>    Brian + signaling design team
>