Subject: Re: [Anima-signaling] GRASP issue 50: Rapid mode

From: Toerless Eckert <[email-masked]>
Date: Mon, 1 Aug 2016 02:19:40 -0700

If i understand the message names correctly, then i think what we
discussed in Berlin was as follows:

- The registrar objective needs to be discovered by every autonomic node in the
   network (because every autonomic node can be bootstrap proxy).
- It would be too much signaling traffic if every autonomic node was sending
  discovery messages. Trying to optimize this would also depend on topology,
  so could be difficult.
- The easiest solution is to define the option for "densely used objectives"
  (like registrars), to periodically send out unsolicited "Discovery Response"
  messages. These "Discovery Response" messages would have to
  - Include Rapid Mode, aka include the Synchronization information
  - Use hopcount MAXHOPCOUNT so they are flooded throughout the network.

Aka: Rapid mode in that case must not be limited to link-local.

In general, i would keep complexity of first RFC as low as necessasry for the
use-case examples we feel we need to support:

- Whenever GRASP does unicast-negotiate between objetive and client, rapid mode
  seems to only provide reduction by 1 round trip. I know how hard web-browser
  vendors like to work to do this with eg: QUICC, but it took them 2 decades to
  arrive at that performance level requirement. I don't think we should introduce
  all this complexity right now unless we have clear near-term requirements.

- Aka: I could happily let go of rapid-mode for now in the general case
  (move into appendix as "candidate extension"), and just figure out how
  we can include unsolicited synchronization data into unsolicited discovery
  messages.

Cheers
    Toerless

On Mon, Aug 01, 2016 at 08:58:12AM +1200, Brian E Carpenter wrote:
> Hi,
> 
> Here's another issue for design team comments.
> 
> My understanding from the discussion in Berlin is that we should retain the Rapid mode
> but also clarify its specification a bit. At the moment the open issue says:
> 
>    o  50.  Is Rapid mode limited to on-link only?  What happens if first
>       discovery responder does not support Rapid Mode?  (Section 3.3.4,
>       Section 3.3.5)
> 
> Feedback please. I'm not quite sure what to do about this. It would certainly
> be simpler if it was on-link only (i.e. discovery loop count limited to 1).
> However, the case where there are two discovery responses and only the 2nd one
> supports Rapid Mode is tricky.
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 17:18:53 +1200

On 01/08/2016 21:19, Toerless Eckert wrote:

...
>   we can include unsolicited synchronization data into unsolicited discovery

We theoretically had unsolicited discovery responses in the design for a while but
never worked out details. They vanished when we added Flood Synchronization
which is an unsolicited announcement. It sends an objective tagged with its source
address. It's pretty much the same thing you are asking for.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Aug 2016 02:25:13 -0700

Thats fine too. Can we walk through an example set of elements in such
a message ?

Also: If we use Flood Synchronization, it sounds as if we would not need
Rapid mode to make that work. In which case my other comment re. Rapid Mode
might apply: unless we find a good example use-case within our existing or
likely near term charter scope, maybe move Rapid mode down into an appendix ?

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 08:43:32 +1200

I'll be honest, I think Bing and I disagree about this. I see Rapid Mode
as a complication for quite a small gain in efficiency - there's actually
more to be gained by running GRASP over UDP instead of TCP, I think. So
I probably agree with you. But I think Bing sees more value in Rapid Mode
than we do.

    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 12 Aug 2016 07:11:38 +0000

I folded the GRASP DT mailing list into the Anima folder. So I missed the large amount of recent discussion. I'll catch up.

Regarding Rapid Mode, when Sheng and I originally designed it, it was mostly inspired by the DHCP 2-message VS. 4-message. 
Me too cannot blow the efficiency. But I think maybe the following scenarios make sense:
1. As Toerless commented on the mic: in IoT scenario, especially the on the lightweight and lossy links.
2. On some "heavy" nodes, which act as kind of central nodes, might reduce the number of maximum concurrent sessions.

Best regards,
Bing

> -----Original Message-----
> From: Anima-signaling [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, August 03, 2016 4:44 AM
> To: Toerless Eckert
> Cc: Anima signaling DT
> Subject: Re: [Anima-signaling] Unsolicited discovery [was GRASP issue 50:
> Rapid mode]
> 
> I'll be honest, I think Bing and I disagree about this. I see Rapid Mode as a
> complication for quite a small gain in efficiency - there's actually more to be
> gained by running GRASP over UDP instead of TCP, I think. So I probably
> agree with you. But I think Bing sees more value in Rapid Mode than we do.
> 
>     Brian
> 
> > Also: If we use Flood Synchronization, it sounds as if we would not
> > need Rapid mode to make that work. In which case my other comment re.
> > Rapid Mode might apply: unless we find a good example use-case within
> > our existing or likely near term charter scope, maybe move Rapid mode
> down into an appendix ?
> >
> > Cheers
> >     Toerless
> >
> >> We theoretically had unsolicited discovery responses in the design
> >> for a while but never worked out details. They vanished when we added
> >> Flood Synchronization which is an unsolicited announcement. It sends
> >> an objective tagged with its source address. It's pretty much the same
> thing you are asking for.
> >>
> >>     Brian
> >
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Aug 2016 15:22:57 +1200

Hi Bing,
> 1. As Toerless commented on the mic: in IoT scenario, especially the on the lightweight and lossy links.

Yes, although on such links we may need CoAP in any case.

> 2. On some "heavy" nodes, which act as kind of central nodes, might reduce the number of maximum concurrent sessions.

Yes, that should be true for synchronization because it saves starting a thread and port for
the request/response. I'm not sure for negotiation, because that will normally be several
messages in each direction so we probably need a separate thread anyway.

I don't think there's anything wrong with the design of Rapid mode. The real question
is whether we want to have it as a MUST implement.

Regards
    Brian