On Mon, Apr 21, 2014 at 3:02 PM, Jeffrey Haas <[email protected]> wrote: > On Mon, Apr 21, 2014 at 07:36:44AM -0400, Jamal Hadi Salim wrote:
> > It may not be the primary deciding criterion but it will > certainly be a big one given the high-throughput desires we have for I2RS. > Do you see a whole BGP table (or larger) being injected/dumped via I2RS? > but I'm happy to provide wiki space for these things to be enumerated. > That would be nice. > The binary encoding of FORCES may help with speed. > It was asserted elsewhere (copied below) that this may only be 3-5% of a > speed improvement. (I had thought I recalled a discussion in netmod(?) at > one point of a BER format for YANG, but my google-fu is failing me.) > A somewhat negative property of XML is that a document is only considered > valid once you have the whole document. Thus, document size may matter. > I think the parsing technique used for XML may help (DOM vs SAX); XML gurus can comment. I have very strong doubts about the 3-5% number stated - but hopefully we can settle that with real numbers. Let me try to handwave (not sure if this is wiki material): On compute: I would expect json to perform better than XML when sending to a browser. In particular given that json is a native format to javascript (but also heard of some decent C/python parsers). If you extended that thought to binary data it will likely perform better than json to an I2RS agent because it is closer to the native format of the I2RS agent ( a lot less translation needed). String processing may be alleviated with newer instruction sets that processor vendors are putting out (glibc uses some of the SSE instructions on x864 when available to do things like strcmp) - but that still will not give you the 3-5% difference claimed. There's also a bunch of vendors who would sell you xml or string processing offload. But i wouldnt call that commodity or depend on that when defining wire format. On extensibility: One could argue that the XML definition would be more extensible than json i.e if you want to be close to native format you pay in reduced extensibility. So if I2RS cared more about extensibility json would not be a good choice. In ForCES we chose to define things in XML to allow for the extensibility; so from that perspective we are closer to XML. The ForCES XML schema/language allows defining things as close as possible to native format. On the wire we take the xml definition and convert it to binary and from that perspective we are closer to json. On wire performance: Should be noted that it is not just about compute resources, but also network resources. If i send 1000 RIB components in ascii (doesnt matter whether it is json or xml) vs the same amount in binary; i would expect the wire resources to be several magnitudes better with binary. It will also be a lot closer to native format the RIB manager uses. Same with sending XML vs json to a browser - json is a native format to javascript and a lot more compact, therefore will perform better. Wire performance can be improved by the classical technique of using compression on the wire. That adds cost to the cost of compute. > I've been working through the various I-Ds in detail. Using the BGP use case > as an example, one of the desires may be to dynamically provision BGP > peering sessions. Given that the I2RS cases are not strictly to provide the > configuration of BGP but are likely a subset of this piece of configuration > in an ephemeral context, this seems to suggest that the I2RS pieces of the > system should ideally have good alignment with configuration systems. Thus, > if YANG were used for provisioning BGP, there's a strong desire for there to > be symmetry in the I2RS model - and thus potentially to share a portion of > the YANG. The same observation would hold for a FORCES implementation of > I2RS. > > Another example is the RIB. > > We want to leverage existing data models in a configuration context while > also providing I2RS extensions for configuration, monitoring, etc. > Lets pick a few use cases that makes sense to I2RS and go with that from an analysis pov. Tom Petch was probably right in saying we needed to start with use cases. I dont want to sell ForCES features that have no meaning for I2RS. > The other half of such a discussion tends to be around letting other > consumers of the encoded information Do Something Useful with it. This does > to some extent argue and influence what your programming model/API is. If > your access to everything is always via strict API, binary encoding a great. This is the modus operandi for what we do today. It allows us to hide whats underneath. The user really has no business knowing we are running ForCES underneath. > But an (IMO) advantage of text-based systems is that it's pretty trivial to > do a lot of things. This is true. The cost may be extensibility as i said above. Note: most of the time the arguement ive heard for ascii is it is useful for the operator for debugging - which clearly not true considering the wire format is always encrypted. This may have been true for smtp or early days of http - but clearly not true for the domain we are talking about. >I suspect I'm not the only one that uses text-based > expansions of binary objects for various work. (And I'll also note that I > leave things in binary format with API access when it makes sense.) > > What I'm really saying is that the ecosystem is likely to expand binary > encoding to text just as much as it's going to move to a binary encoding. > I am juggling that in my head and not seeing going ascii from binary. (I guess given my reading of your context above i am seeing base64 encoding of binary data ;->). You probably mean something else > > Would you say section 4.5.3 of RFC 5812 provides a good example of that? > (Just to pick one from my reading.) > If you are talking about the API, it is closer to what http does (restful, few verbs and many nouns which would be close to URIs). Think of a restful binary setup. Something restful like http would be sufficient to describe it. Section 4.5 defines the schema i.e how one would define/model the resources (eg RIB). The API is what the protocol provides the few verbs to act on resources/nouns. So an API call is of the form: Verb <resource noun> [optional data] Bringing the comparison to http again: a ForCES SET would be equivalent to http POST/PUT/PATCH etc. There are some CRUD semantics like append/exclusivity etc that were discussed but missing from the protocol. I gave a high level view at the SDNRG WG in ietf86. Also my gap analysis summarizes some things. Evangelos is planning to give webinars/tutorial that people wanting to get familiar with ForCES could attend. > Jamal, while the point is being made perhaps a bit less than pleasantly, > there is certainly something there to discuss: The work Jan cites has a > depth of models that cover many pieces of functionality similar to those > that I2RS looks to address. They've done enough work against Yang/Netconf > to have an idea of the remaining gaps. > > While I agree that within the limited scope of the FORCES documents that > I've read that the modeling language and to a large extent the protocol can > similarly address the problems, I haven't the depth to determine whether > similar coverage of I2RS cases can be done within FORCES and what would need > to change. It is also unclear aside from the binary encoding / more atomic > transaction model (note, I haven't read restconf yet for proper comparison) > that FORCES would bring vs. Yang/Netconf. That comparison is what the WG > needs in somewhat greater depth than the existing gap analysis. > So my take on this is: Lets have the informational description of what I2RS needs - perhaps by going over use cases. It is easy to provide the ForCES view of those model. cheers, jamal _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
