Subject: [ipfix] Multiple levels of Reliability and Directionality

From: [email-masked]
Date: Thu, 07 Nov 2002 09:45:47 -0500

Does IPFIX need to support multiple levels of reliability
and directionality?

The applications IPFIX needs to support are quite varied
and have differing needs in terms of reliability. Devices 
also have varying needs in terms of directionality.

I would like the WG to consider requirements on the protocol 
to support a tiered approach meet these needs. 

Direction is either bi-directional or uni-directional. I've split 
reliability into 3 categories...

        High   - Little to no data loss
        Medium - Minimal data loss is accepted
        Low    - Data sent is best effort

The six combinations are shown below...

               | Uni  |  Bi
        -------+------+---------
        High   |  1   |    4
        -------+------+--------
        Medium |  2   |    5
        -------+------+--------
        Low    |  3   |    6

I think (IMHO) the most likely combinations are...

        3. Low reliability and uni-directional. This will be used
           where the device and collector are in close proximity,
           there is high volume and some data loss is acceptable for
           the given application. Applications such as Attack/Intrusion
Detection
           Traffic Profiling, etc...

        5. Bi-directional medium reliability. This will be used
           where high volume and increased reliability are needed.
Applications
           such as Usage-based Accounting where 95th percentile billing
           model is used. Or even Traffic Engineering where network
policy
           decisions are based on the data collected.

        4. Bi-directional high reliability would be used where the
           Usage-based Accounting application has strict requirements
           on data loss.

Does IPFIX need to support multiple levels of reliability
and directionality?

Paul

--
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: Tue, 12 Nov 2002 00:16:49 -0800

Jeff Meyer suggested (message #1415) that:
   NFv9 and IPDR seem like they may fit
   the bill jointly.  NFv9 for UDP based unreliable
   delivery and IPDR for TCP/SCTP based reliable delivery.

I disagree: two is too complicated and unnecessary (tedious details follow
in the rest of this note).

Also, I think that Jeff does IPDR a disservice here, in that IPDR-streaming
also provides application-level ACK (as does CRANE). Jeff, please correct me
if I mis-read the document. [By the way, is there an official version for
the IPFIX WG? I could only find protocol documents on the IPDR website.]

I'll discuss how to remove reliability from the point of view of CRANE;
others might wish to point out where there are differences with their
protocols.

The protocol document doesn't discuss behaviour for fail-over as being
outside the scope of the document, so there might be some misunderstanding
of what application-level ACK provides. At minimum, it should provide:
   - persistency on the receiver and subsequent ACK is done by a combination
     of timer and #records (ACK for slow data rates, #records for high
rates)
   - sender times out on ACK, whether because of slow network, slow
receiver,
     or slow downstream persistency processing
   - fail-over to one or more secondary receivers when application-level ACK
     not received within timeout
   - multiple "streams" to allow N-to-1 redundancy (CRANE provides this
     within its protocol; presumably IPDR would use multiple TCP connections
     to provide similar capability)
   - ability to absorb bursts of data, with fail-over/fail-back if one
     receiver is overwhelmed and then recovers

But I digress ... it isn't necessary to have the complication of two
protocols just to support unreliability. I have already shown how template
negotiation does not lead to a complex implementation for a *minimal*
conforming implementation (#1382, #1386, #1381). In a similar spirit, the
bi-directional protocols can be made unreliable as follows:

Step 1 (for protocols that have application-level reliability):
   Remove the template negotiation.
   Remove any multiplexed stream in the protocol (e.g., CRANE's
   "sessions"), replacing by separate transport channels.
   Remove the application-level ACK. For the implementation,
   the effects are:
      (a) receiver doesn't need to provide persistency on the
          received data.
      (b) exporter does not need to maintain a queue of data waiting
          to be ACKed.
    At this point, we have "partial uni-directionality" - there is
    still transport-level ACK and flow control (TCP or SCTP).

Step 2:
    Change from TCP/SCTP to UDP, ensuring that all records can be
    put into a single packet. For efficiency, multiple records
    can be packed into a single packet but they must not span records
    because of the possibility of packet loss. If there is no data
    record number, add one (application-level protocols already
    have record numbers).

Step 1(b) is a little subtle, if the implementation on the
exporter does non-blocking I/O (which is what we did in our CRANE
implementation: we didn't want to slow down the main processing
on the network element). Most TCP/SCTP stacks have relatively
small buffers (typically no bigger than 256K), so the application
must still keep its own buffer and make its own decisions on
discarding records when the application buffer fills up.

Step 2 has its own subtlety: how to deal with template changes.
I don't see how this could be done without some kind of acknowledgment,
whether by a reliable TCP channel, or by something like RADIUS's
acknowledgments -- after all, packet losses occur occasionally even
in the best families -- and it's pointless to broadcast packets when
the receiver doesn't know their format.
So, one must have either a predetermined set of record definitions
or some bi-directionality for acknowledging format changes.

References:
http://ipfix.doit.wisc.edu/archive/1382.html
http://ipfix.doit.wisc.edu/archive/1386.html
http://ipfix.doit.wisc.edu/archive/1381.html
http://ipfix.doit.wisc.edu/archive/1221.html
http://ipfix.doit.wisc.edu/archive/1415.html

- peter

> -----Original Message-----
> From: majordomo listserver [mailto:[email-masked]]On Behalf
> Of [email-masked]
> Sent: Thursday, November 07, 2002 6:46 AM
> To: ipfixx
> Subject: [ipfix] Multiple levels of Reliability and Directionality
>
>
>