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

[Toerless Eckert <[e-mail]>]

Thanks, very well stated.

On Fri, Aug 12, 2016 at 09:04:31AM +1200, Brian E Carpenter wrote:
> 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
> > 

-- 
---
Toerless Eckert, [e-mail]