Subject: RE: [ipfix] Observations on Selection Process and Requirements

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 11 Mar 2003 15:34:07 -0500

Nevil,

  Thanks for your dual role comments.

  My mistake on the IESG/IETF "mandate"/"consensus", thanks for the
correction.

  Regarding Diameter as the universal accounting protocol, I feel in
general,
as you point out, that when you mix in the "other 2 A's", what you end up
with is something which is adequate for all, but certainly not optimized
for the needs of "accounting only" device behavior.

  Specifically, an accounting only model implies to me an effectively
unidirectional
transfer of information from the exporter to the collector.  Now if you want
some reliability, you'll need some feedback from the application OR you'll
want some non-volatile storage and a pull based model.

  Another observation regarding pure accounting is that there is likely a
large
amount of homogenous "records" being sent.  A template based approach, vs.
a TLV approach helps reduce the per record overhead on transfer.  CRANE, 
NFv9 and IPDR all take a similar approach.  In fact the encoding of the
flow records themselves are pretty near identical.

  This "pure accounting" model is not unique to IP Flows, but also includes
"Layer 7 probes", Application Servers, WAP Gateways and Gateway devices in
the 3G space.  Having had to develop the consumer end for all these
protocols, 
I can say that I can see no good reason that all of these use different
protocols,
other than the lack of an established convention/standard protocol.

  I'm hoping that IPFIX can be done in such a way that does accomodate
this broader industry need, which I have to deal with on a daily basis.

  And if we truly do separate the concerns around the lines defined
in the requirements draft, I think it is highly acheivable, and will
not unduly burden (or burden in any way) IPFIX's specific area of
interest around IP Flows.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Nevil Brownlee [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 11:55 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: [email-masked]
> Subject: Re: [ipfix] Observations on Selection Process and 
> Requirements
> 
> 
> 
> Hello Jeff:
> 
> Some comments in response to your 'Observations on Selection 
> Process ..'
> 
> <wg chair hat ON>
> Your point 3, use of UDP transport.  As Allison pointed out, the use
> of congestion-aware transport for new standards-track protocols is an
> IETF consensus, not an IESG mandate.
> 
> Of course people who implement new applications may choose, for
> whatever reason, to use transport which is not congestion-aware.
> That's fine, but it won't conform to the standard.  Or to put it
> another way, to be standards-compliant, a vendor has to give customers
> the ability to use congestion-aware transport.
> 
> Having said that, this is a rathole which the WG spent a lot of time
> exploring in the first half of last year - we're not going to 
> go there 
> again.
> </wg chair hat ON>
> 
> Now your other points:
> 
> <wg chair hat OFF, i.e. these are my own opinions>
> 
> I agree that RFCs 2975 and 2924 are relevant.  They came from the
> AAA WG, which was strongly focussed on Accounting.  Their end product
> is DIAMETER, which is designed to be an all-inclusive protocol for
> all three A's.  So if we want a one-true-faith Accounting protocol,
> we should all use DIAMETER.
> 
> Alas, reality isn't like that.  A lot of the complexity in DIAMETER
> comes from its need to handle Authentication and Authorisation across
> multiple provider realms, so Accounting is only a subset of DIAMETER.
> 
> Again, there are lots of network operators (not to mention 
> researchers)
> using LFAP, NetFlow, RTFM, etc. to gather flow data from routers and
> switches, who do it to gain understanding of how their network is
> behaving, and who probably have no interest in using that data to
> recover costs.  IPFIX started in this context, with the notion of
> setting a single standard for exporting flow data from routers and
> switches.  That's only part of making a 'universal accounting 
> protocol,'
> but it would nonetheless be a very useful step forward.  And 
> one which,
> to me at least, seems achievable.
> 
> Your remarks about the Data Model are interesting.  In writing the
> 'attributes' part of RFC 2924 I was trying to make a list of all the
> attributes in use or defined at the time, and looking at 
> extensible ways
> to encode them.  Although it would be nice to have everyone use a
> single description/encoding method, I'd be happy to settle for two
> or three methods, with the user choosing the one which is 
> most suitable
> for any particular situation.
> 
> To sum up: although it would be nice to have IPFIX become the one
> method everyone uses for all accounting-related flow data export,
> that seems a distant goal right now.
> 
> Since IP mediation vendors are coping now with the variety of flow
> export systems in use, concentrating on something which only handles
> export from routers and switches would be a fine goal for IPFIX.
> That way, AAA servers could become the logical clearing-house, taking
> flow data from routers and switches, and passing it - along with
> user identification, etc. - to IP mediation (i.e. billing) systems.
> 
> </wg chair hat OFF>
> 
> See you in San Francisco!
> 
> Cheers, Nevil
> 
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
> 
> 
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/
> 

--
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: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 14 Mar 2003 15:33:26 -0500

Randall,

  Thanks for bringing up the SCTP.
 
  My point about expense/immaturity of SCTP is that if I pick any random
machine that I want to plunk down collection software on, odds are it will
NOT have SCTP.

  Since SCTP is an OS level service, adding support to this is something
that some people may think twice about, vs. adding a piece of software.

  I didn't see Microsoft listed here.  Given the number of likely desktops
which might want to collect, it would be nice to have.

  Go to Microsoft's website and search for SCTP.  There is ONE link.
And this hit is simply because they have a copy of the IP protocol table
(SCTP is #132).

  So, that's what I meant.

  I'm sure you could get access to it, but it ain't seamless today, like
TCP.  So, I'd be much happier with a solution which only relied on user
space changes vs. kernel changes.

Regards,

  Jeff Meyer

-----Original Message-----
From: Randall Stewart (cisco)
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: [email-masked]'
Sent: 3/14/03 9:57 AM
Subject: Re: [ipfix] Observations on Selection Process and Requirements

Jeff:

A couple of quick comments to some of what you said :>

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

>  
>  3.  The use of UDP as a transport for flow information is widely used
>  today.  Despite the statement in section 6.3.1 of the IPFIX
requirements
>  document that the protocol MUST  be congestion aware, it is likely
that 
>  the "backpressure" associated with congestion aware protocols will
put 
>  an unacceptable burden on SOME common observation points in SOME 
>  situations. 
>  
>    This seems to be an item which has been avoided because of the IESG
>  mandate on congestion aware protocols, however it seems quite
relevant
>  to this particular domain.  Cisco has just recently provided a
mapping 
>  of their proposed NFv9 to SCTP, but at the same time left the door
open 
>  to use variants of SCTP which continue to allow them to "fire
>  and forget".  There is probably a meaningful technical issue here, 
>  which should not be ignored.
>  
>

Yes there is a technical issue.. and I think the PR-SCTP draft removes
the
concern and thus is why NFv9 has a mapping to SCTP and specifically will
 use PR-SCTP's features...

>    I.e. although from a collector/reliablity perspective, TCP is much
more 
>  desirable,  especially given the relative immaturity and expense of
SCTP 
I am a bit curious about these comments above...

There have so far been 5 SCTP-bakeoffs (including connect-a-thon last 
year)... and
all of these went well. There are a huge number of implementations if I 
remember
some of the major ones (my aplogies if I miss any .. there are a lot 
more ...):

1) Linux has an implementation (it will be standard in 2.6 and is 
available now in 2.5)
2) IBM AIX had a killer version at the last bakeoff.
3) The BSD's have the version that I wrote and can be found in the KAME 
release.
4) HP has interop'd a version
5) Compac (now I guess HP :->) has shown up with a version
6) Sun has a version..
and a huge number of telco mfngr's  (Nokia, Erricison and Seimens).. to
name a few...  and there were lots more as well from smaller
companies...
the big ones stick in my mind :-D

the last bakeoff had close to 20 participants.. and every single 
implementation interop'd fine...

So, since it is available free... and is in LOT of implementations I am
not
sure what you mean by the "expense" of SCTP?

And as far as maturity goes.. well.. as of the last bakeoff the fact 
that every implementation
was able to interop with every other one is to me a sign that it IS 
maturing quite nicely...

As far as PR-SCTP.. I know from the BSD work it was an addtion of about 
20-40 lines of code
and I think the same is true for the IOS version of SCTP...

So I am a bit baffeled by your statements... especially when PR-SCTP 
will allow
an ipfix device to be able to send completely reliable and partially 
reliable data over
the same congestion controlled association... a very desireable thing in

my view..

R

>  implementations on general purpose platforms, there seems to be a
desire 
>  to avoid TCP on the part of a major player in the flow observation 
>  equipment space.  This should be explored!
>  
>
>  
>

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 14 Mar 2003 15:43:21 -0500

Thanks Peter I failed to mention the lack of Java.

Combine this with the lack of free (any?) support on Windows, and I'd have
to say, this doesn't sound very compelling in the near term.

-- Jeff 

-----Original Message-----
From: Peter Ludemann
To: 'Randall Stewart (cisco)'
Cc: [email-masked]
Sent: 3/14/03 12:34 PM
Subject: RE: [ipfix] Observations on Selection Process and Requirements

Randall Stewart wrote Friday, March 14, 2003 9:58 AM:

> There have so far been 5 SCTP-bakeoffs (including connect-a-thon
> last year)... and all of these went well. There are a huge
> number of implementations if I remember some of
> the major ones (my apologies if I miss any .. there are a lot more
...):

The latest list of implementations (Oct 2002) seems to be:
http://www.sctp.org/archive/0123.html and
http://www.sctp.org/archive/0129.html ... Is there anything else?

Are there any implementations of SCTP that I can use from Java without
wrapping in JNI? (That is, the way I can use TCP and UDP without
wrapping in
JNI.) For Java, I could only find http://www.sctp.org/archive/0282.html
,
which recommended using JNI.

- peter

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