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

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 11 Nov 2002 09:43:23 -0800

I would second Paul's proposal about several models of operation.

The charter talks about billing and accounting. Some people will also use
IPfix for security/intrusion detection, usage-based billing and other
related tasks as stated on the requirements draft. 

I sent an email about this before. We are claiming the protocol will be used
for a lot of different purposes but seem to be afraid of taking the
necessary steps to uphold that. If we do not have a highly reliable protocol
(at least as one model of operation), then usage based billing, intrusion
detection and to a certain extent QoS Monitoring should be taken out of the
requirements draft (see Appendix section). 

But as said, I also understand that if somebody just want to do some traffic
profiling, a higher reliability might be too much, that's why I said I
second Paul's proposal. 

regards,

Reinaldo

ps: What is the definition of a "typical" Internet reliability?

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 12:08 PM
> To: Randy Bush
> Cc: [email-masked]
> Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> 
> 
> -- Randy Bush wrote on 09 November 2002 17:16 -0800:
> 
> >> 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>
> 
> 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
> 
> > <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
> >
> 
> 
> 
> --
> 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:08:18 -0800

Randy Bush reminded me in the attached that I had forgotten to identify
myself as a <vendor/>, while he was representing an <operator/>.

<vendor whoAnswersRFPsFrom="operator">
Octet counting may well be sufficient for Randy and his <operator/> (I don't
know his business model), but many of the <operator/>s I deal with demand
far more in terms of detailed flow reporting (these <operator/>s are
worldwide, including US, Japan, Europe). We would have lost business if we
could provide nothing more than octet counting. Some (not all) <operator/>s
want more flexibility in their billing models. And because IPFIX proposes
its data be used for (amongst other things) billing, I must disagree with
Randy and say that IPFIX should provide flow data. The flows can always be
summed or otherwise aggregated to provide just octet counts.

I hope that Randy and I do not disagree about reliability. (Some
<operator/>s want even more -- fully redundant probes, data collection,
deduplication, persistency, etc.)
</vendor>

<editorial>
As one who remembers with fondness the days when the Internet was free of
commercialism (and undergraduates) I feel a bit uneasy in representing a
vendor, who might seem to be pushing something upon the IETF. But we are not
marketers trying to create demand that isn't there -- we are reacting to
<operator/> requests. Someone must pay for the Internet; and we're just
trying to process the data that will allow a wide variety of usage models,
so that natural selection can take us to better systems (which I hope will
be more pervasive and less expensive; and will still allow undergraduates).
Unfortunately, the stickiest part often is data collection -- which we're
hoping that IPFIX will help solve by choosing a useful standard.
</editorial>

- peter

> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, November 11, 2002 9:54 AM
> To: Peter Ludemann
> Subject: Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
>
>
> > 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.)
>
> you forgot the <vendor> tag.
>
> randy

--
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/