Subject: [Anima] GRASP issue 51: Flooded objectives

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Aug 2016 09:15:36 +1200

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2016 13:24:03 +1200

Hi,

I'm guessing from the quietness of the list that many people are on
vacation, but for now, here is the proposed action on this point:

-  a change to the Flood message format that adds a TTL field
and a locator field (in the same format as in a Discovery Response).
Both of them can be null (which means infinity for the TTL).

- add a TTL field to the Discovery Response too. This makes the Flood
and Discovery Response message formats essentially identical.

We'll also add a recommendation that flooded objectives should be
repeated at a suitable frequency. Otherwise, there is a problem
for new or sleeping nodes.

Regards
   Brian