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

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

Hi Toerless, and design team,

Here's a draft message to the WG. Comments? (It doesn't cover everything
in the thread - when we get these points settled, there are other points
we need to come back to.)

<draft message>

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.

</draft message ends>

Regards
   Brian


On 10/08/2016 18:41, Toerless Eckert wrote:
> Let me know if a higher bandwidth connection helps. I am currently
> in germany time zone and could set up a webex.
> 
> Cheers
>     Toerless
> 
> On Wed, Aug 10, 2016 at 01:07:55PM +1200, Brian E Carpenter wrote:
>> On 09/08/2016 18:39, Toerless Eckert wrote:
>> ...
>>> Maybe we put together an update of the discussion on the list ?
>>
>> Yes. We're doing exactly what we are supposed to: confronting
>> the design of GRASP with details of some of the use cases.
>> I will draft something - but there's quite a lot of meat
>> here so it will take a bit of chewing.
>>
>>    Brian
>