Subject: [i2rs] Clients-Agents protocol prioritization

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 29 Apr 2014 10:19:14 -0400

This is back again with node overload.
Our experience with ForCES made us prioritize events and request-response
differently. This is important only when there is an overload case.
As an example if i had sufficient cycles/bandwith/ram space to respond to either
an ADD or an event - I choose to use those resources to process and respond
to the ADD; which means events are not reliably delivered to the clients.

I think something like this would be needed for I2RS.

cheers,
jamal

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Apr 2014 19:48:41 -0400

> I think something like this would be needed for I2RS.

In our architecture, we are permitting multiple clients to communicate with
one agent, so this somewhat compounds the issue.  It does permit some amount
of discussion of what we can do about a few issues in this problem space:

- Pipelining: If you can submit multiple requests but they must be satisfied
  in the order submitted (e.g. as per netconf), the amount of work that a
  given request implies has impact on overall throughput.
- Even if you're able to bypass this to some extent using multiple client
  sessions, if the resources you're working with rendezvous at a common
  blocking point (e.g. some RIB service that has internal mutual exclusion
  semantics), then this can be problematic.  We're not doing locking and
  thus we're not exploring the semantic of saying "would block".  
- The work in a reply may be huge.  Consider a single client having in its
  work queue a "add route" and a "give me the entire BGP RIB".  Ordering
  will clearly have impacts on how quickly the add route operation
  completes.

I suspect that (mutex example aside), operational semantics across more than
one client session may address many of these issues.  What isn't clear is
what needs to be addressed in our documents about such issues.

-- Jeff