Subject: [ipfix-req] IPFIX Reliability Requirement

From: "Tal Givoly" <[email-masked]>
Date: Thu, 14 Nov 2002 11:20:30 -0800

Nevil and all,

We still do not have consensus on 'reliability' in the IPFIX protocol.

I would like us to achieve consensus regarding two points:
1. Standardizing NetFlow is not the charter of the working group (although
NetFlow is a perfectly viable candidate protocol and may be selected after
evaluation).
2. Addressing the issue of reliability of the protocol (to whatever degree
is agreed upon), is in scope of the effort of the working group.

Once we agree regarding these two points, we can dedicate some effort to
finally bring to conclusion the discussion regarding reliability and how it
relates to the requirements of the protocol.

I am not proposing 'carrier-grade' reliability for all. But I believe that
it can be demonstrated (see below) that some kind of reliability IS part of
the IPFIX charter and that the various kinds of reliability MUST be
addressed properly if IPFIX is to standardise on a widely-useful protocol.

The rest of this submission includes justification for the above two points
as well as a proposal on how to move forward to resolve the ambiguity and
lack of agreement regarding the reliability requirement.

Below is an attempt to summarize the debate regarding the reliability
requirement.

The views presented thus far includes the entire spectrum from "no
reliability, let's just standardize NetFlow" to carrier-grade billing-level
reliability, and a large number of possible variations to achieve some
middle ground. It seems that that middle ground is being sought in order to
provide greater applicability to the IPFIX protocol.

My initial thoughts are that this debate will not settle in the mailing
list. However, in attempt to help bring this issue to conclusion, I put
forth a presentation of the various views presented and potential method to
resolve the issue at hand.

As one of the people that have an interest in resolving this issue (as we
should all if we are to achieve consensus), I have tried to objectively
round up the views presented - stemming from the charter of the WG, the
requirements document, and individual views of users presented on many
threads:

----------------------------
Extract from Charter, regarding reliability
(http://www.ietf.org/html.charters/ipfix-charter.html):

"As such, there is a need in industry and the Internet research community
for IP devices such as routers to export flow information in a standard way
to external systems such as mediation systems, accounting/billing systems,
and network management systems to facilitate services such as Internet
research, measurement, accounting, and billing."

and

"The protocol must run over an IETF approved congestion-aware transport
protocol such as TCP or SCTP."

One of the specific goals:

"Ensure that the flow export system is reliable in that it will minimize the
likelihood of flow data being lost due to resource constraints in the
exporter or receiver and to accurately report such loss if it occurs. "

----------------------------
Extract from Requirements draft, regarding reliability
(http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-07.txt):

5.1.  Reliability

   The metering process MUST either be reliable or missing reliability
   MUST be known and indicated. The metering process is reliable if each
   packet passing the observation point is metered according to the
   configuration of the metering process. If, e.g. due to some overload,
   not all passing packets can be included into the metering process,
   then the metering process MUST be able to detect this failure and to
   report about it.

6.3.  Data Transfer

   Requirements for the data transfer include reliability, congestion
   awareness, and security requirements. For meeting these requirements
   the exporting process can utilize existing security features provided
   by the device hosting the process and/or provided by the transport
   network. For example it can use existing security technologies for
   authentication and encryption or it can rely on physical protection
   of a separated network for transferring flow information.

6.3.1.  Congestion Awareness

   For the data transfer, a congestion aware protocol MUST be supported.

6.3.2.  Reliability

   Absence of reliability of the data transfer, for example caused by
   loss or reordering of packets containing flow information, MUST be
   indicated.

   Please note that if an unreliable transport protocol is used,
   reliability can be provided by higher layers. In such a case only
   lack of overall reliability MUST be indicated. For example reordering
   could be dealt with by adding a sequence number to each packet.

   Flow information might get lost before it is processed properly by
   the collecting process. A means to gauge the amount of loss of flow
   information MUST be available from the exporting process and/or the
   collecting process. Possible reasons for flow information loss
   include resource shortage at the exporter, loss of packets between
   exporting process and collecting process, etc.

   If the exporting process is capable of detecting loss of connection
   to a collecting process, it SHOULD be able to perform failover to a
   specified backup collecting process.

Appendix: Derivation of Requirements from Applications

   The following table documents, how the requirements stated in
   sections 3-7 are derived from requirements of the applications listed
   in section 2.

   Used abbreviations:
      M = MUST
      S = SHOULD
      O = MAY (OPTIONAL)
      - = DONT CARE

   -----------------------------------------------------------------------.
      IPFIX                                                               |
   ----------------------------------------------------------------.      |
   E: QoS Monitoring                                               |      |
   ----------------------------------------------------------.     |      |
   D: Attack/Intrusion Detection                             |     |      |
   ----------------------------------------------------.     |     |      |
   C: Traffic Engineering                              |     |     |      |
   ----------------------------------------------.     |     |     |      |
   B: Traffic Profiling                          |     |     |     |      |
   ----------------------------------------.     |     |     |     |      |
   A: Usage-based Accounting               |     |     |     |     |      |
   ----------------------------------.     |     |     |     |     |      |
                                     |     |     |     |     |     |      |
   | Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 5.    | METERING PROCESS                                             |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 5.1.  | Reliability             |  M  |  S  |  S  |  S  |  S  |      |
   |-------+-------------------------+-----+-----+-----+-----+-----+  M   |
   | 5.1.  | Indication of           |  -  |  M  |  M  |  M  |  M  |      |
   |       | missing reliability     |     |     |     |     |     |      |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 6.3.  | DATA TRANSFER                                                |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 6.3.1.| Congestion aware        |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 6.3.2.| Reliability             |  M  |  S  |  S  |  S  |  S  |  M   |

<Tal: table above has been spliced together for readability only>

From the above alone, my understanding (supported by many other opinions I
found in the archives), is that addressing the potential issue of
reliability is definitely within the scope of the working group - by
definition of the charter, from the the requirements and from the attention
this matter has received. A whopping 319 messages have some reference to
"reliability". One cannot claim there has not been much discussion on the
topic. This is largely due to many interested participants with varying
views of the subject.

Much of the discussion may be due to ambiguity regarding the definition of
what does "reliability" really means. Further, people are still debating
whether addressing the issue is even in scope to be addressed by the working
group, including distinguished senior IETF members.

The history of this debate is very old. For instance, you can look at
http://ipfix.doit.wisc.edu/archive/0817.html where Nevil summarizes:

> >    ** Need to reach consensus on two major points:
> >        a. We know we need reliable transport.  Do we
> >           also need unreliable?

vs.

Randy Bush wrote (http://ipfix.doit.wisc.edu/archive/0006.html)

"I assume this is standardisation of "NetFlow".
If yes, some non-proprietary way of indicating that
they are standardising existing practice would be
nice and help avoid confusion such as Brian's."

More recently Randy wrote:

In http://ipfix.doit.wisc.edu/archive/1401.html
"
> Somehow, the requirements discussion suffers from a split:
> There are requirements resulting from the intention of
> standardzing a highly reliable metering standard for precise
> accounting (and billing). Differing from these are requirements
> for a simpler metering standard more oriented at what I would
> call "typical Internet reliability".

<ad> the original goal, which the iesg thinks was chartered, is the
latter.  </ad>"

In http://ipfix.doit.wisc.edu/archive/1413.html:
"...but the primary goal of this wg is to reconcile some _current_
inter-vendor incompatibilities,
fix congestion control, etc."

The examples just serve to demonstrate the extremes that this debate has
gone through.

If this was the case (we are merely trying to standardize NetFlow), we
shouldn't have gone to all the trouble and gotten to a protocol evaluation
phase to begin with. As we are going through that process (based on the
charter and the agreed-upon requirements), we should conclude, FIRST, that
the standardization of "NetFlow" is not the objective of the working group.

Also, 4 of the protocols proposed currently propose to use congestion-aware
protocol as underlying technology (while the NetFlow proposes to be extended
to use such a protocol).

I propose we that the SECOND conclusion is that we achieve consensus on
whether or not reliability needs or need not be addressed. I propose is that
that consensus is that the matter at least needs to be addressed and is
covered by the WG charter and requirements draft.

If both of the above are maintained as the consensus, we should arrive at a
common definition of levels and modes of reliability and refine the
requirements document to have several well-defined (unambiguous) levels of
reliability. For each of those, we would then try to achieve consensus on
which are MUST, SHOULD or MAY levels of compliance. Only then would we be
able to get to the business of comparing the protocols against less
ambiguous, agreed-upon requirements in this area.

If it can be determined that we arrive at consensus regarding these first
two points, I volunteer to document the (potentially) desired levels of
reliability so that a debate regarding the level of conformity be launched.

Nevil, perhaps this item is worthy of discussion as part of the agenda in
the IETF WG meeting itself.

Tal
____________________________________________

Tal Givoly
Chief Scientist
XACCT Technologies, Inc.
2900 Lakeside Drive
Santa Clara, CA 95054
http://www.xacct.com

Direct:  408-330-5747
Tel:     408-654-9900 x 5747
Fax:     408-654-9904
E-mail:  mailto:[email-masked]
____________________________________________

--
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: "Carter Bullard" <[email-masked]>
Date: Thu, 14 Nov 2002 15:25:15 -0500

Gentle people,
Here is an excerpt of some mail that I sent to Peter, that
didn't make it to the list.  Understanding the nature of
an IPFIX transport failure helps to put my concerns
regarding reliability in perspective.  The failure scenario
below is but one of them, but IMHO the important one.

Carter

> Here is a scenario that I imagine.  If IPFIX is using TCP,
> for instance, what will be the nature of IPFIX record loss?
> There will be none, as long as the TCP is healthy.  When
> the TCP fails, and the receiver finally reconnects, possibly
> seconds/minutes later, the client can discover the
> number of records that were missed, possibly even the number
> of flows, bytes, packets, etc ...., through the use of the
> reliability mechanisms inherent in the IPFIX protocol, ie
> sequence numbers and integrity reports.   But there is nothing
> in the IPFIX WG's charter to specify that the IPFIX device must
> have any of these lost records to retransmit.   Routers
> definitely won't have them around.  Some expensive probes
> will, but IPFIX must support both of these devices.
> 
> To require that IPFIX support reliability through single
> channel receiver ACK'ing puts far too many constraints on
> the design and function of IPFIX devices, something that
> is out of scope of the WG.
> 
> Now if IPFIX were designed such that the receiver could
> declare what records it was interested in, then you could
> implement a selective retransmission mechanism through
> the use of multiple IPFIX sessions.  After you reconnect
> and start getting the current stream, you discover you missed
> 27,356 records.  Get another IPFIX session with the device
> and ask just for those 27,356 records, if the device supports
> it.  That sounds reasonable to me, given the nature of IPFIX
> record loss characteristics.
> 
> Carter
> 
>