Subject: Re: [Anima] two EST question/suggestions

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Oct 2017 17:21:58 -0400

The text in the ACP document which I'm moving into the BRSKI document says:

               In the above (recommended) example the period could be 60 seconds and the
               indicated ttl of 180000 msec means that the objective would continuously be
               cached by ACP devices even when two out of three messages are dropped in transit
               (which is unlikely because GRASP hop-by-hop forwarding is
               realiable).

In a PPP overlay, the M_FLOOD's can clearly be sent over TCP.
And that part is reliable, but once inside the GRASP daemon, whether or not
an M_FLOOD is relayed really depends upon whether or not there is available
buffer space.

You have to drop traffic going into the TCP links if there is no room
available (vs blocking on write).  So I am not sure the () message above
is justified.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Oct 2017 13:13:25 +1300

> an M_FLOOD is relayed really depends upon whether or not there is available

There's also a statement that the relay should throttle the rate of
relaying (look for "MUST limit the total rate") both for M_DISCOVERY
and M_FLOOD, as an anti-DOS precaution.

> available (vs blocking on write).  So I am not sure the () message above

Yes, I think we must always regard multicast as unreliable. As GRASP
says, both M_DISCOVERY and M_FLOOD are repeatable operations.

    Brian