Dean, In your slides, IIRC, at the meeting you illustrated several daemons all interacting with the agent doing different things. 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 protected]> 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 protected]> 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 protected]> wrote: >>> >>> On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim <[email protected]> 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 protected]> >>>> 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 protected]> 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 protected]> >>>>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>>>>> To: Dean Bogdanovic <[email protected]> >>>>>>>> Cc: Andy Bierman <[email protected]>, "<[email protected]>" >>>>>>>> <[email protected]>, Martin Bjorklund <[email protected]>, >>>>>>>> "<[email protected]>" >>>>>>>> <[email protected]>, "<[email protected]>" <[email protected]> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman <[email protected]> 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 protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
