On Sun, Apr 20, 2014 at 10:46 PM, Jan Medved (jmedved) <[email protected]>wrote:
> > > On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <[email protected]> wrote: > > >On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic <[email protected]> > >wrote: > > > > > >> It comes down how many transactions are required? Will you updated 1000 > >> routes in single transaction or in 1000 transactions. > >> > > > >Take your pick. The point is it boils down to how that is modelled and > >carried > >over the wire (and influences those decisions). > > > >> From my perspective there are two important metrics for i2rs > >> throughput > >> and > >> latency > >> > > > >Now we are talking. > > > >> > >> IMO, I2RS agent has to provide as high as possible throughput and add > >>minimal latency to the >process. What is the throughput required? Don't > >>know at the moment. I saw some request in high >single digit thousands > >>per second, but not sure about use cases. On the latency side, you want > >>it as >close to 0 as possible, but that will be highly platform > >>dependent. > >> > > > >Agreed. > > Both throughput and latency are meaningless from the standardization point > of view - they both largely depend on the underlying system. > > Speaking for NC/Y implementations that I¹ve been involved with, the > throughput of the Netconf Agent itself is much larger than the rest of the > system, and its latency is negligible compared to the rest of the system. > This happens to be true both for an embedded agent (XR), where ultimately > both throughput and latency are determined by how fast you can program > hardware, and for the controller, where both throughput and latency depend > on how fast you can shove things into a data store. > > Rather than focusing on devising a super fast binary encoding for the > protocol (which will speed up maybe 2-5% of the overall CPU cycles), we > need to have a self-describing schema-based message encoding which allows > for creation of tools that generate most of the agent and client code. > NC/RC/Y gives us exactly that. The raw speed of the agent (optimized > protocol processing, message encoding, etc.) must be weighed against the > ease and speed with which new APIs can be added to system - we have > Moore¹s law for CPUs, but not for human brains ;-) We need to compensate > for that with tooling/automation. > > > Great points. There are some specific areas where the data modeling language can impact protocol performance. The most significant is the handling of default leafs. A well-designed data model will pick reasonable default values for most leafs. Since defaults are mandatory-to-implement in YANG, a client can omit defaults when creating a new data structure. This can have a much bigger impact on throughput than binary encoding. A protocol can be fast by being clever, not always just by brute strength compression. For example, clever use of PATCH to update the absolute minimum set of objects is smaller and faster than replacing entire subtrees with PUT. The biggest impact a data modeling language can have on the protocol is wrt/ human usability and tool automation. Andy > > >> I have to start doing some PoCs to see what can and can not do with > >>existing tools. If those tools >work, then good. If those tools don't > >>work, then back to the drawing board. Until things work, keep on >moving > >>with what works and try to find break points. > >> > > > >But i do believe there are limitations which are not obvious without > >contrasting against requirements. > > > >> You can add your comments to the existing drafts. > >> > > > >I would gladly do - but i worry whether the discussion is about crowning > >some > >solution instead of meeting such objectives; if the WG decides to move > >in that > >direction i would be happy to contribute. > >There's material floating, the old protocol draft; Joel pointed to the > >architecture > >draft covering model requirements. Andy mentioned possible "stretch" > >requirements. I think what would be appropriate is one draft for the model > >and one for the protocol with gap analysis. > > > >>> > >>> Unfortunately - we are not having that kind of useful discussion and i > >>> feel like a broken > >>> record asking for requirements. > >> > >> I believe we have a set of requirements. It is in > >>draft-rfernando-i2rs-protocol-requirements. > >>You can always comment that draft and argue pro and con each requirement. > > > >Glad we are bringing that draft into play;-> How does restconf fair > >against it? > > Reasonably well. When we evaluated restconf against these requirements (I > am a co-author), the major deficiency found was lack of notifications in > restconf, which was addressed in a subsequent restconf revision. There are > still things that would have to be added (for example, client identities), > but this can be addressed either in the protocol or in models. There is > nothing *structural* in restconf that would prevent it from satisfying the > requirements set. > > And as I said earlier in this thread, about 80-90% of what I can think > that we can do with I2RS (and it¹s much, much more than just RIB > programming ;-) ) can be addressed with NC/RC/Y today. > > > > >Note: The draft is a good starting point but is missing as an example > >the issue of > >latency and throughput. > > > >cheers, > >jamal > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
