Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 1 May 2014 16:48:54 +0000

Jamal,

On Apr 29, 2014, at 9:47 AM, Jamal Hadi Salim <[email-masked]> wrote:

> Dean,
> 
> In your slides, IIRC,  at the meeting you illustrated several daemons
> all interacting with the
> agent doing different things.

Not completely correct. I have only one agent talking to multiple daemons and that is the analytics agent. Routing and filtering agents in the picture are talking only to its respective daemons. With the analytics agent, having one for each daemon is an overhead imo.

Dean

> In our case it will very likely be
> multiple daemons doing
> different things for the agent (and sometimes remote machines). In any
> case, this may end up being
> an implementation issue.
> I have another issue I will post probably under a separate topic:
> Prioritization.
> 
> cheers,
> jamal
> 
> On Mon, Apr 28, 2014 at 4:23 PM, Dean Bogdanovic <[email-masked]> wrote:
>> Jamal,
>> 
>> There is only one agent to one daemon. There is no scenario of one agent to multiple daemons.
>> 
>> There are multiple clients to one agent.
>> 
>> So agent is depending on the speed of daemon and agent should protect overloading daemon with requests, so it can police requests from clients.
>> 
>> Dean
>> 
>> 
>> On Apr 24, 2014, at 9:56 PM, Jamal Hadi Salim <[email-masked]> wrote:
>> 
>>> I was mostly referring to overload conditions (of both compute and
>>> wire resources).
>>> It is feasible for a client not to be able to keep up (eg a table dump
>>> response; i.e a single
>>> request resulting in a large fast bulk response). However,
>>> the more interesting case is for a daemon overload as a result of some
>>> client transaction;
>>> assuming possibly N daemons talk to an agent on the south bound
>>> multiplexing to M clients
>>> on the northbound, where M>>N - and how to deal with the client(s)
>>> that are responsible for the
>>> overload without adversely affecting the other clients that dont
>>> contribute to overload.
>>> Some of this could be implementation issues.
>>> 
>>> I think l misunderstood what you and Andy were saying to imply you
>>> meant M equals N equals 1.
>>> 
>>> cheers,
>>> jamal
>>> 
>>> 
>>> On Thu, Apr 24, 2014 at 4:03 PM, Dean Bogdanovic <[email-masked]> wrote:
>>>> 
>>>> On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim <[email-masked]> wrote:
>>>> 
>>>>> I was more looking at the agent - it brokers between clients and the
>>>>> RIB subsystem
>>>>> as shown in figure 1 of the architecture doc. Different clients bring
>>>>> different latencies/capacities.
>>>>> Congestions will kick in,
>>>> how does client latency influence agent? The agent sees request coming in from different authorized clients at a rate and it is processing those requests. The agent will depend on the daemon performance, but not on client.
>>>> 
>>>>> reliability requirements will need to be
>>>>> considered. And there may
>>>>> be need to signal these details to the clients (SIP proxying is the
>>>>> closest i can think of).
>>>>> You cant solve this problem by just inserting a reliable transport
>>>>> where the i2rs protocol
>>>>> runs.
>>>>> 
>>>>> cheers,
>>>>> jamal
>>>>> 
>>>>> On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern <[email-masked]> wrote:
>>>>>> No, there is no requirement that the client is a broker.  He may be, or he
>>>>>> may not.  And the scope of his brokering, if he is a broker, may be
>>>>>> application specific or more general.
>>>>>> 
>>>>>> We have placed requirements to be able to provide traceability when the
>>>>>> client is brokering.  This is as much because even a non-broker may be
>>>>>> acting on behalf of several different applications.
>>>>>> 
>>>>>> As far as I can tell, the fact that a client may itneract with multiple
>>>>>> agents does not in itself palce new protocol or model requirements on the
>>>>>> system.  If we wanted inter-agent atomicity, then there would be
>>>>>> requirements.  But we explicitly decided that was out of scope.
>>>>>> 
>>>>>> Yours,
>>>>>> Joel
>>>>>> 
>>>>>> 
>>>>>> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote:
>>>>>>> 
>>>>>>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman <[email-masked]> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Which drafts shows 1 I2RS client performing a network-wide edit
>>>>>>>> across N locked I2RS agents?
>>>>>>>> 
>>>>>>> 
>>>>>>> There is a requirement to allow only one client to own write access to
>>>>>>> a specified object in order to avoid locking. There is nothing objecting
>>>>>>> to a client being able to write to multiple objects as long as that rule
>>>>>>> is met.
>>>>>>> 
>>>>>>>> The agents do not coordinate with each other.
>>>>>>>> The clients do not coordinate with each other.
>>>>>>>> 
>>>>>>>> This is currently out of scope for the I2RS protocol.
>>>>>>>> 
>>>>>>> 
>>>>>>> Both assertions true.
>>>>>>> But what i was responding to is:
>>>>>>> There are multiple clients that connect to the same agent.
>>>>>>> And a client can connect to multiple agents.
>>>>>>> 
>>>>>>> I believe that such a requirement _may_ call out certain features in
>>>>>>> the protocol. Essentially the agent is a broker.
>>>>>>> 
>>>>>>> cheers,
>>>>>>> jamal
>>>>>>> 
>>>>>>>>> cheers,
>>>>>>>>> jamal
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Andy
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: Jamal Hadi Salim <[email-masked]>
>>>>>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM
>>>>>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model
>>>>>>>>> To: Dean Bogdanovic <[email-masked]>
>>>>>>>>> Cc: Andy Bierman <[email-masked]>, "<[email-masked]>"
>>>>>>>>> <[email-masked]>, Martin Bjorklund <[email-masked]>, "<[email-masked]>"
>>>>>>>>> <[email-masked]>, "<[email-masked]>" <[email-masked]>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman <[email-masked]> wrote:
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Dont think so.
>>>>>>>>> 
>>>>>>>>>> Network locking across devices is out of scope.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I have same opinion as you on this one, just wanted to spell it out one
>>>>>>>>>> more
>>>>>>>>>> time explicitly, as I heard some discussions where network locking was
>>>>>>>>>> coming up.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Either I am misunderstanding both of you or both of you misunderstood
>>>>>>>>> the
>>>>>>>>> requirement.
>>>>>>>>> The idea is to allow a single writer per object as a starting point.
>>>>>>>>> OTOH, if you really mean what you say then I violently disagree.
>>>>>>>>> 
>>>>>>>>> cheers,
>>>>>>>>> jamal
>>>>>>>>> 
>>>>>>>>> PS:- Changing the topic so this is not lost in the noise because i think
>>>>>>>>> that
>>>>>>>>> the many clients-single agent brings needs for other protocol
>>>>>>>>> requirements.
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> i2rs mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> i2rs mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> i2rs mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>> 
>>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 4 May 2014 06:50:25 -0400

Hi Dean,

I stand corrected then.
So let me instead use figure 1 of the statement problem doc that just
got published.
Or use figure 1 of arch document.
If any of the resources accessed via the agent are daemons (which
translates to async
access) then this (proxying) issue will surface. But again this may
all be implementation
specific.
To make it clear: the apps C-E of client P on figure 1 of the
architecture doc *is* susceptible to such
a challenge.

cheers,
jamal.