Subject: RE: [ipfix] Forming consensus on IPFIX default protocol

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 13 Nov 2003 03:52:10 -0500

Danny,

  Thanks for the additional information.  Sorry I couldn't personally attend
the IETF, but dollars for travel are tight in our neck of the woods.

  I certainly agree with your sentiment around UDP.  Regardless of IETF
policy, I suspect this will dominate for some time.

  The one concern is the "implement what you like aspect".  The decision
dictates the mandatory support of SCTP, which is fine if you're running on
Linux, but is much more problematic on other platforms.  There are key
differences between deploying kernel space and user space implementations.
And although a user space implementation of SCTP is readily available it
effectively allows only one process to use SCTP, because all IP traffic
which is targeted at the SCTP IP protocol id is targeted to a single user
space process.

  As a product developer who needs to address customer's desires to run on
Linux, HP-UX, Solaris and Windows, this mandatory aspect raises serious
concerns, this is doubled when we are talking about Java based collectors.
  
  In an ideal world all platforms would have SCTP out of the box and Java
would have a nice object oriented class of sockets which supports it.  This
is not the world today, nor do I expect it to be the world for some time.

  If we're all willing to wink and agree that we're really just going to use
UDP for the forseeable future, and that the choice of SCTP is really
targeted at some distant nirvana-esque future, then I guess it doesn't
matter what is chosen.  This seems to be the status of Diameter today
(although the wink is around TCP vs. SCTP).

  If however we want to deal with the brutal reality of the playing field
today and define a protocol which can be readily realized on any number of
platforms, then the only choice (given IETF constraints) is TCP.  As Stuart
Smally says, "Denial ain't just a river in Egypt."

Regards,

  Jeff Meyer

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Danny McPherson
Sent: Wednesday, November 12, 2003 9:34 PM
To: ipfix wg
Subject: Re: [ipfix] Forming consensus on IPFIX default protocol

I saw lots of folks raise their hand when the "How many
folks would like to see SCTP be the default" (~twice as many
as opposed to TCP) question was asked and a great number
of those were NOT Cisco employees -- not that it's even a
relevant argument here as we're all individuals!

I've never liked the hand-raising thing much anyways, and
I'd prefer "humming" or nothing at all in the meeting, but
nonetheless...

As a large consumer of flow information in my day job, I
suspect UDP will be all that matters in the near term (for
a number of presumably obvious reasons), and when folks are
ready to make a change SCTP does have some appealing
attributes.

And of course, you're always welcome to implement anything
you'd like...

-danny

On Nov 12, 2003, at 6:09 PM, MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:

> Nevil,
>
>   I guess I haven't heard anyone other than Cisco strongly supporting 
> SCTP,
> but
> then again that was my impression for NFv9 vs. the other candidates.  I
> guess
> will just sit back and let John Chambers do the driving...

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

--
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: Juergen Quittek <[email-masked]>
Date: Thu, 13 Nov 2003 17:26:39 +0100

Jeff,

Thanks for describing the application and customer view.

On the manufacturer's side, I also see problems with PR-SCTP.
Many small routers run proprietary operating systems or
commercially available  real-time OSs. For all these
it will take a long time until stable implementations
of PR-SCTP are available.

A MUST requirement for PR-SCTP would keep these devices
out of the IPFIX business for the next two years.

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 14 Nov 2003 19:11:14 -0600

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

Some comments.

>which is targeted at the SCTP IP protocol id is targeted to a single user
First this is totally untrue. The very first SCTP user space implementation
employed a deamon with inter-process communication. This is a very
workable arrangment if you want to use a user space library and it
prevents just such a situation.

>concerns, this is doubled when we are talking about Java based collectors.
Jim Bound of HP has told me that HP DOES have a kernel implementation of
SCTP.

A gentlemen (whom I can't name) has assured me that SUN will attend the
next bakeoff (June of 2004) and bring an implementation that will support
all extensions, is kernel based and is downloadable as a binary module from
the SUN web site.. A module that may not yet have all the extensions will
be available by the end of the year. So for sun you can at least use SCTP
after doing a pkg-add within two months.

Java is not a problem either. We use Java internally and already have a shim
that does the collection for UDP to avoid using the Java sockets layer since
the developer considered it inefficent... (or so I am told)... to change 
to SCTP
is a minor tweak to his shim (a few lines of code). This is very dooable 
since
Java after all is extensible and easy to work with :->

BSD of course has the KAME version that can be added.

The only vendor that does not yet have a core kernel stack is M$ .. but 
there
are stacks for sale on M$... Which would mean purchasing it and going
through an installer.. Something anyone that has added anything to a M$
machine is familiar with [slide to the bottom and hit the accept key to
the legal garbage, and then press next repeatedly :-D].

Now sometime soon.. when I get back home next week  I will get a
web page up listing in one place everywhere SCTP is available and who 
has it.

It will be on

www.sctp.org

>is not the world today, nor do I expect it to be the world for some time.
Adding a package to a box to get SCTP in is not hard. On a sun box doing
a

pkg_add sctp-package

does not take a lot of effort... and it is all coded to the sockets api 
just like
linux, just like BSD... not sure about the HP version.. I have added
Jim Bound who might be able to answer more specific details.

Jim, can you help Jeff out? He seems to be unaware that you have
a SCTP kernel version at HP?

>(although the wink is around TCP vs. SCTP).
This is all just nonsense. You can get SCTP if you want it. Does it show up
in every box yet, no. Can you get it for every box if you really want 
it, yes.

Deployment arguments are not the sound basis for engineering decisions. We
decide the best transport for the protocol and use it, especially when 
you can
find SCTP available in all major O/S flavors.. it may take you a little more
work.. aka "pkg_add xxx". But having to do a few extra steps for some of
the O/S's is not a reason to NOT make the right technical decision!

R

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 14 Nov 2003 19:16:16 -0600

> of PR-SCTP are available.

I am not too sure about this either.. I know that QNX Nuetrino has
a SCTP stack that includes PR-SCTP. They seem to be one of
the major R-T O/S vendors... I am not sure if VXworks or Vertix
has SCTP... If I remember right some of my former Motorola colleages
are working ... I think it was VXworks... that they had a SCTP 
implementation
on.. I will ping a friend of mine and ask him.. I know they had one of the
two.. just can't remember which one..

So there are at least 2 out of the 3 major Rtos vendors.. and the third 
may even
have it as well :->

R

---

From: Benoit Claise <[email-masked]>
Date: Wed, 19 Nov 2003 17:02:33 +0100

>policy, I suspect this will dominate for some time.
I fully agree with the comment above, as a few people mentionned already 
on the list. The market/the customers will decide at the end what they need.
UDP will still dominate for some time but on the other hand, you're 
pushing for TCP to get an earlier adoption of IPFIX!
And that's exactly my point in favor of SCTP-PR. Let's get the right 
transport protocol, the one that will give the most advantages compared 
to UDP! As a consequence, UDP might dissappear as an export transport 
protocol. And if there is a small delay to get a IPFIX/SCTP-PR 
implementation compared to IPFIX/TCP, is this a big issue as UDP "will 
dominate for some time"?  ;)

Regards, Benoit.

---

From: Alex Audu <[email-masked]>
Date: Wed, 19 Nov 2003 16:04:49 -0600

I know I am thousands of e-mails behind. I appologize for that. But I
wish people would stop making this lame argument that "SCTP is kernel
space protocol".  It is just totally bogus! And to say there is
only one user space implementation but it is not multiprocessing is just
incredibly disingenuous as well.

I voted for SCTP because I know it is a better protocol. That is from
experience. I have articulated my reasons (all technical) on this list. And
if we can get past the emotional argument that CISCO may be pushing
SCTP, you'll agree that SCTP is a better choice than TCP for IPFIX.
It should be pointed out that SCTP's design was a group affort involving
people from Motorola, Cisco, Siemens, Nortel, Ericsson, Telocrdia and
other organizations.

I hope we can get this behind us and move on.

Regards,
Alex.