Subject: RE: [ipfix-eval] Discussion of Candidate Protocols

From: Stas Khirman <[email-masked]>
Date: Wed, 2 Oct 2002 20:34:28 -0700

Peter Ludemann wrote:
> My comments on Jeff Meyer's comments (hopefully this 
> discussion won't get
> indented too many levels by those who rebut me).
> 
>     - IPDR  - much richer and more formal extensibility model,
>         leveraging industry standard XML-Schema.
>         Compactness as good as other candidates (after
>         negotiation of "templates"/"descriptors"), simple
>         set of operations.
> 
> I would argue that a hierarchical format is a Bad Thing. 
> History repeats
> itself; and the XML people are finding out what old-timers 
> already knew:
> that there were good reasons why relational databases supplanted
> hierarchical and network databases on the 1970s ... if 
> anybody wishes me to
> bore them with the details, just ask ... or read other 
> people's opinions
> such as http://www.dbazine.com/pascal4.html

I do not think that relational/XML database example is valid at this point -
even good old DB applications aren't build on top of one big flat table. In
general, telecommunication applications are dealing with complex structural
objects. It is why virtually all Telco standards are based on structural
data/signal representations (old good ASN.1!).  IPDR.org had recognized that
we are not dealing with a "flat" objects - it is why structural ( I prefer
this term over "hierarchical") representation are suggested. XML is chosen
as a convenient tool to express and validate this structure. BTW, earliest
IPDR draft used traditional ASN.1 approach, but it had been replaced by XML
- myriad debugging, testing, support, processing and so on tools are
available (many for free). Binary encoded IPDR ( as suggested in IETF
submission) is free from major XML obstacles (transmission overhead and
parsing performance) but retain major XML advantages (structure,
extensibility, possibility for verification and wide set of tools to
support).
Bottom line: IPDR suggest to use structural, formal , extensible model to
complex objects reports. XML is just a tool to express this formalization
(one of many!!).

> 
>     - Diameter - less compact due to AVP encoding model.  
> Extensibility
>         model formalized, but not provided as a machine readable
>         document.  Overhead of acking makes this seem too heavyweight
>         for the requirements as specified.  Finally the requirement
>         for a recorder to support the SCTP protocol seems prohibitive,
>         since this may require kernel support lacking on several OS's.
> 
>     - LFAP - has a limited (numeric id based) extensibility model.
>         Protocol is relatively simple.  The encoding is tag/len/value
>         meaning it will be less compact than IPDR or NFv9.
> 
> Compactness is a Good Thing when sending thousands of records per
> second. This is not just an issue of bandwidth; it is also an issue
> of processing time -- if you know exactly how a record is laid out,
> you can process it faster. In some cases, you can avoid copy 
> operations,
> which can be a significant cost at high data rates. I don't see how
> tag/len/value encoding can have as high performance as externally
> defined formats.
> 

Hm, I do not think that memcopy operation could have a significant impact.
Let's assume we are dealing with 10,000 records per second 100 bytes each.
It is mean that in worst case we have to copy 1Mbyte - 250,000 copy
operations per second on 32 bit processor. I'm sure it will take only a
fraction of one percent on any normal CPU, am I wrong? BTW, majority of TCP
stack implementations are doing few memory copies anyway. 

> BTW, doesn't the Diameter spec say that it can use UDP, TCP, or SCTP?
> (I would love to require SCTP for CRANE; but as it is not wide-spread
> yet, we must allow the possibility of TCP for now.)
> 
>     - NFv9  - compact, but extensibility model (templates) don't
>         provide the set of information which IPDR does.  Relatively
>         simple.
> 
>     - CRANE - proprietary vendor format.  More complex than is
>         needed for IPFIX use case (20 different operation codes).
>         Template based (like NFv9), has similar lack of formalism
>         in actual definition of extensions.
> 
> "Proprietary vendor format" is irrelevant. Netscape, LFAP, 
> NetFlow will
> all be released under IETF rules if they are adopted as standards.
> 

Availability of the open-source tested multi-vendor implementation is not a
negligible reason for protocol choice. I have no detailed information about
DIAMETER, but IPDR implementation is tested, corrected, extended and adopted
by collective effort of something like 20-30 vendors ( Jeff , please correct
me if I'm wrong in numbers).

> The alleged complexity in CRANE is to provide the necessary level of
> reliability and flexibility in the templates. One specific design goal
> was to allow the exporter to be informed of which fields were needed,
> so that it could adjust its processing accordingly (for our 
> PacketSight
> probe, we can see roughly 3:1 performance change, depending on the
> amount of metrics and attributes that are collected). If 
> these are left
> out, the number of operation codes drops by 1/3. Remove the operations
> for multiplexing sessions on a connection (which would be unnecessary
> if we could mandate SCTP) and we're down to 11 operations. 4 of these
> are for flow control; 3 are for status reporting.

Indeed, CRANE capability to eliminate some of attributes is a nice feature,
however it is not clear why it have to be done using in-band signaling. It
certainly overcomplicates protocol and make it hard manageable when someone
deal with one to many ( multiple consumers) communication. Also, many
accounting applications have to use "store and forward" model which breaks
in-band configuration approach. In IPDR case, configuration could be
expressed as a specific XML-Schema and delivered to IPDR producer out-band (
it is not clear if this configuration step have to be standardized at all -
any ideas are very welcome). Transmitted IPDR records always refer to
specification used to produce them - you could store records for years
without fear to lost association with a specification.
IPDR ability to specify in machine/human readable format structure of
transmitted information is a crucial feature when you deal with a
financially sensitive information. This feature provide consuming
application with abilities to verify, store , convert, process or transform
into another format without fear of misconfiguration or version
incompatibility. (Elimination of the external registration process is one
more small, but nice advantage - just remember RADIUS port conflict
problem.)

Disclaimer: Being a author of early IPDR drafts, I have to be considered as
a VERY biased IPDR advocate.

Regards
Stas Khirman

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: "Peter Ludemann" <[email-masked]>
Date: Sat, 5 Oct 2002 12:07:55 -0700

> stack implementations are doing few memory copies anyway.

And some TCP implementations are zero-copy.

All I can tell you is that one of our partners had memory bandwidth
issues getting data off the collection board into main memory
for transmission; and that minimizing memory-to-memory operations
was important.

[email-masked] wrote Wednesday, October 02, 2002 5:54 AM:

> 	Having done a fair amount of tuning on a collector I find
> 	it interesting that your performance hinged on a memory
> 	copy. In my experince performance was limited by how fast the
> 	disk writes are.

I agree on the collector performance tends to be constrained by I/O.
But collectors are often bigger boxes (also doing other things
with the collected data, such as aggregating, correlating,
filtering, etc.) and have less stringent real-time requirements.

Usually reliable sources have told me that certain vendors' switches
quietly stop collecting flow statistics when CPU exceeds 70% or so.
These same sources have therefore installed probes to collect the
data. So, minimising CPU usage on the network element is important!

- peter