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

[Toerless Eckert <[e-mail]>]

Inline

On Sat, Aug 06, 2016 at 02:39:35PM +1200, Brian E Carpenter wrote:
> Hi Toerless, just drilling down on two points (I have not ignored the rest,
> but these condition other aspects):
> 
> On 05/08/2016 20:34, Toerless Eckert wrote:
> 
> ...
> >> 1. We specify that the source address is cached with the flooded objective, and that
> >> multiple copies are kept if there are multiple sources.
> > 
> > Yes, but "source" really must be the ASA transport address, aka: 
> >    source = {ACP-ULA-IPv6-address, proto=TCP, ASA-GRASP-TCP-port}
> 
> Here I have a little problem. Unless you plan to use GRASP messages for
> the entire process, it isn't GRASP's business what protocol and dynamic
> port are to be used.

I do not parse that sentence. Can you rephrase ?

> So I think the protocol and the port need to be
> fields in the flooded objective itself, not derived automatically by
> GRASP. Does that make sense?

We need to be able to distinguish in the caches announcements for the same
objective from two different ASA on the same autonomic node. Therefore the
"source" needs to have another distinguisher beside the IPv6 address of the
autonomic node. This is not an issue that the individual ASA can solve becaue
the cache is kept by GRASP.

The distinguisher can be any ID, but i proposed to use the ASA's TCP port number
through which it runs GRASP becaude this ID does already exist and is unique.
So no new ID-allocation code to write.

This TCP port number will NOT be used to construct the transport port of any
service connection!

Example:

    Registrar ASA objective announcement:
        source = { ACP-ULA-IPv6-address, proto=TCP, Registrar-GRASP-TCP-Port }
        ....
        Payload:
        EST-adress: { proto=TCP, port=<Registrar-EST-port> }

Registrar ASA starts, it gets a TCP port for its GRASP unicast messages
GRASP puts that <Registrar-GRASP-TCP-Port> into the source of all Objectives from this ASA.

Then the Registrar ASA opens a TCP server port for the EST protocol. Then it
announces the objective.

The Bootstrap-Proxy constructs the transport address of the EST connection
by combining the TCP port from the payload EST-address with the IPv6 address
of the source. The TCP port of the source is only used to send/receive GRASP
messages from/to that ASA - which happens by the GRASP library. 

And of course, this could be a TCP or UDP port number. I personally think TCP
is easier even if there is more overhead because i don't need to bother about
fragmentation (for GRASP).

> ...
> > 
> > If the announcer of a flood sync announce dies, how would its cache entries
> > ever be deleted ? On nodes that have an ASA interested in the objective,
> > the ASA can look at expiry time and tell GRASP to expire the entries. But
> > how about nodes without such ASA ?
> 
> Is it a problem? The useless flooded objective would sit there until the
> cache overflows and it gets deleted by the LRU algorithm.

Normally, U) means "used", and i think we can not do this:
Check my algorithm for a bootstrap proxy finding the best registrar. It will retrieve
from GRASP all those registrar cache entries, so you can't figure out which one
it "Uses" without additional API. The only thing the currently planned APIs
would give you is an indication when the client ASA tries to use an objective
and it's broken. But it will try only what it thinks are the best. Not the others,
so they won't get good LRU treatment.

We need to have a fairly high frequency of periodic flood-sync messages anyhow.
Else a newly rebooted device will not learn them well. Or we need to make
the protocol more complex by generating additional triggered flood syncs for newly
booted devices. Aka: one flood sync every 30 seconds . Then it makes a lot of sense
to also time them out.

> > Aka: expiry_time looks to me like a logical GRASP header parameter so that
> > we can GRASP without ASA expire flood sync cache entries.
> 
> We can do that. It's a choice: extra bytes in every flood message versus
> no default expiry mechanism, just LRU cache expiry.

I'll vote for extra bytes.

Cheers
    Toerless

> I'll review all your points after we clear these ones up.
> 
> Thanks
>     Brian

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