Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

From: Juergen Quittek <[email-masked]>
Date: Sun, 10 Nov 2002 01:53:31 +0100

Hi all,

There are still several requirements issues under dicussion
on the list. We (the authors) only integrated changes into
the document, for which we sensed rough consensus. If you
disagree with our judgement, please speak up.

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".

Anyway, below please find the list of changes between versios -06
and -07 of draft-ietf-ipfix-reqs.

    Juergen

1. Replaced all occurrences of "sampling rate" by "sampling frequency".

2. Appended to Section 6.3.2.:
   "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."

3. Replaced in 6.1.:
   "  5. source TCP/UDP port number
      6. destination TCP/UDP port number"
   by
   "  5. if protocol type is TCP or UDP: source TCP/UDP port number
      6. if protocol type is TCP or UDP: destination TCP/UDP port number"

4. Inserted in 6.1.:
   "  7. if protocol type is ICMP: ICMP type and code"

5. Replaced text of Section 5.4.:
   "The metering process MUST be able to generate timestamps for the
    first and the last observed packet of a flow. The timestamp
    resolution MUST be at least the one of the sysUpTime [RFC1213],
    which is one centisecond."
   by
   "The metering process MUST be able to generate timestamps for the
    first and the last observation of a packet of a flow at the
    observation point. The timestamp resolution MUST be at least the
    one of the sysUpTime [RFC1213], which is one centisecond."

6. Replace in Section 8.1:
   "measurement and reporting" by "the metering process and
    the exporting process"

-- [email-masked] wrote on 08 November 2002 13:38 -0500:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Flow Information Export Working Group of the IETF.
>
> 	Title		: Requirements for IP Flow Information Export
> 	Author(s)	: J. Quittek et al.
> 	Filename	: draft-ietf-ipfix-reqs-07.txt
> 	Pages		: 29
> 	Date		: 2002-11-8
> 	
> This memo defines requirements for the export of measured IP flow
> information out of routers, traffic measurement probes and
> middleboxes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-07.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ipfix-reqs-07.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipfix-reqs-07.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

--
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: Randy Bush <[email-masked]>
Date: Sat, 09 Nov 2002 17:16:57 -0800

> call "typical Internet reliability".

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

<operator> i do not understand how _flow_ measurements can be a
_rigorous_ basis for billing.  in my world, we use octet counting
for that kind of application.  </operator>

randy

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 11 Nov 2002 18:08:13 +0100

> <ad> the original goal, which the iesg thinks was chartered, is the

Thank you, Randy, for clarifying this (again).

To all on the list:
Do you think there is consensus on sticking to the original charter
goal, or are there strong opinions on getting towards higher reliability
of flow metering and export.

My preference is going for "typical Internet reliability" and leaving
high reliability out of the scope.

    Juergen

---

From: [email-masked]
Date: Mon, 11 Nov 2002 12:08:14 -0500

>    "  7. if protocol type is ICMP: ICMP type and code"

	Hopefully this is a SHOULD. Many platforms do not
	distinguish flow by ICMP type code.
>     one of the sysUpTime [RFC1213], which is one centisecond."

	I'm speaking up on this one! Not all platforms timestamp
	each and every packet and thus cannot give the timestamp
	for the last observed packet. 

	We need to allow for inactivity based platforms which means the 
	last packet was seen within the window of the inactivity timer.

---

From: "Tal Givoly" <[email-masked]>
Date: Mon, 11 Nov 2002 09:41:05 -0800

Hi,

I feel strongly that "typical Internet reliability" is insufficient to make
this standard of value for a large set of applications.

Although there are many applications that can work in "typical Internet
reliability", accounting for usage (whether for billing, interconnect,
peering, settlements, charge-back or other uses), which our company has been
involved in the past 5 years, is suffering from unreliable methods leading
to cost-ineffective deployments to afford any sort of reliable mechanisms.
The ability to support carrier-grade requirements is left as an "excercise"
for the carriers - one which they struggle with.

If we limit the protocol by considering protocols that cannot be (even
optionally) reliable, we lose a significant portion of the value of such a
protocol altogether. Adopting one of the existing techniques yielding
"typical Internet reliability" would merely leave the state of affairs as is
today - yet another protocol that needs to be implemented in the
network/service elements.

The evolution of the Internet has clearly focused, first and foremost, on
offering ability to launch services, then on making them secure and scalable
enough to actually be used, and finally, it is time to make them business
aware. In order to launch services of value, it must be possible to
scalably, reliably, account for these services. Protocols exposing the
service usage should, at least optionally, have reliability mechanisms - so
that carriers interested in such applications would not need to deploy
ineffective and ultimately poorly designed systems.

Tal
-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Juergen Quittek
Sent: Monday, November 11, 2002 9:08 AM
To: Randy Bush
Cc: [email-masked]
Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

To all on the list:

    Juergen

--
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: Randy Bush <[email-masked]>
Date: Mon, 11 Nov 2002 09:48:21 -0800

<ad>

> I feel strongly that "typical Internet reliability" is
> insufficient to make this standard of value for a large set of
> applications.

this is trivially true.  the question is whether such applications
are, or should be, in the charter of this wg.  currently they are
not.  if you wish to change that, then a change to the charter will
be needed.  in this case, as it would seriously affect many
parties, that will be a rather inclusive process and success is far
from sure.

it would be nice if the wg could abjure mission creep.

</ad>

randy

---

From: "Peter Ludemann" <[email-masked]>
Date: Mon, 11 Nov 2002 09:50:37 -0800

Randy Bush wrote Saturday, November 09, 2002 5:17 PM

> for that kind of application.  </operator>

Au contraire, octet counting is so 20th century & dot-com.

Because of a need for _rigorous_ billing, and for flexibility in
billing/business models, I am currently working on projects that
use (amongst other things) for billing:
  - dynamic IP addresses (which we dynamically map to customer ID)
  - protocol classification (including dynamically assigned ports
    such as for FTP and H.323)
  - octets, adjusted for resends, IP, TCP, application header overhead
    (don't want to charge end-users more when network quality
     gets worse)
  - content type (MIME type, etc.)
  - QoS (response time, packet loss, etc.)

The octet values are just one part of what we get from "flows". Service
providers who work with just octet counts are in danger of commoditizing
their business; far better to work with the detailed information that flows
provide.

Anyway, if all you wanted was dreary old octets, you could easily get them
by just summing over flows.

By the way, the data we collect for billing is also used for network
engineering. Of course, for network engineering, the reliability
requirements would be lower; but it's nice to be able to get all the data
from a single source (well, actually it's not, but you don't want to be
bored with issues of redundancy, fail-over, etc.).

[As these projects pay the bills, I have zero time to contribute to the
other IPFIX documents, unfortunately.]

- peter

---

From: Jeff Meyer <[email-masked]>
Date: Mon, 11 Nov 2002 11:30:14 -0800

Hi,

   I completely agree w/ Tal's response here.

   The charter states that the IPFIX protocol is meant to
address the following use case:

   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.

   Accounting and billing are not activities which respond
well to unreliable delivery of information.

   IP Flows are a very good source of information for billing,
since it provides identity information for both the consumer
and the target service (IP addresses and ports) as well as
metrics on the usage of that flow (duration, pkts, bytes, etc.)

   In a deployment where accounting is to be done via
flows, it is imperative that the metering process and
the exporting process provide a reliable delivery stream.

   It may be the case that an unreliable stream is "good
enough" (apparently so given the popularity of NetFlow),
but many many customers I see don't think it is "good
enough" for their applications.  In some cases, given
the lack of alternatives they'll go with this anyway.

   So, I think the idea of different profiles, potentially
addressed by different protocols may be the best
solution to addressing the charter.

   In particular, 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.

Regards,

   Jeff Meyer