Subject: RE: [ipfix] STCP as a default transport not

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 14 Oct 2003 21:35:06 -0400

Hi,

  I tried to articulate my reasoning why SCTP may prove to be a 
barrier for implementors of IPFIX in non-Linux based collectors
in the e-mail:

  http://ipfix.doit.wisc.edu/archive/2044.html

  The statement, "well, we have an implementation", doesn't mean
that other interested parties will have the time/patience to 
acquire or develop one themselves.

  In fairness I will note that there is one open source user 
space implementation that I could find at:

   http://www.sctp.de/sctp-download.html

  Links to Linux and FreeBSD kernel implementations are available
off of:

   http://sigtran.org/ and http://www.sctp.org/

  Nonetheless, the time and testing effort to get a multiplatform
Java based collection engine running on TCP vs. SCTP is significant.
Consider the project plan for each activity and tell me there's no
barrier associated w/ SCTP.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Peter Lei [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2003 3:13 PM
> To: [email-masked]
> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe'; 
> 'Randall Stewart
> (cisco)'; 'Benoit Claise'; [email-masked]'; [email-masked];
> 'Reinaldo Penno'; [email-masked];
> [email-masked]
> Subject: Re: [ipfix] STCP as a default transport not
> 
> 
> Alex Audu wrote:
> > As far as I know, I don't know of any thing specifically 
> that specifies that
> > any transport protocol must be in USER or KERNEL space. Based on
> > what features are important to you, you could deploy SCTP 
> in kernel space
> >  for speed and efficiency, or in user space for 
> flexibility, kernel safety,  and
> > ease of coexistence with other protocols.
> 
> Exactly... I guess my original comment/question was why was having
> SCTP in kernel "(where SCTP belongs)" was a "problem"... that SCTP
> in kernel space places no issues on "ubiquity".
> 
> Perhaps the original reference was that for his particular situation
> (and yours too it seems) is that SCTP was only available in 
> user space.
> 
> --peter
> 
> > TCP has been deployed both in user and kernel spaces and 
> our in-house
> > SCTP was deployed in user space.
> > 
> > Regards
> > Alex.
> > 
> > Peter Lei wrote:
> > 
> > 
> >>>Robert,
> >>>
> >>>  I agree with your points, with the one caveat that user 
> vs. kernel space
> >>>(where SCTP belongs) makes the ubiquity step just that much harder.
> >>
> >>Please clarify this statement for me... SCTP is in kernel 
> space for both
> >>Linux and xBSD platforms... there is a normal sockets API 
> for SCTP.  There
> >>is even a TCP "compatible" API such that we have been able 
> to port SSH,
> >>FTP, Apache web server, and Mozilla browser by changes a 
> hand few lines of
> >>code (in the socket() call change the IPPROTO_TCP or "0" to 
> IPPROTO_SCTP).
> >>
> >>
> >>>  I especially agree with the focus on "restrictions imposed by the
> >>>transport".
> >>>
> >>>  I believe that the message set defined in the IPFIX 
> protocol to date is
> >>>relatively transport neutral.  Hence the additional 
> overhead of specifying
> >>>the binding details to TCP and PR-SCTP seem relatively 
> straightforward,
> >>>i.e. Diameter seemed to have no trouble here.
> >>>
> >>>  So all I'd like to see is a preservation of that 
> transport independence
> >>>and explicit bindings to TCP and PR-SCTP (in addition to 
> the existing UDP
> >>>binding which is prevalent today).
> >>
> >>I don't see a problem with this... none of the transports 
> being discussed
> >>places any changes/constraints on the IPFIX protocol itself.  It MAY
> >>require the IPFIX application layer choice of "do I want to 
> this reliable
> >>or unreliable" which might mean choose a different socket 
> descriptor or
> >>change a parameter in my send call (in the case of 
> PR-SCTP)... but these
> >>are known apriori by the application.
> >>
> >>
> >>>  The conversation seems to have devolved into a "You only 
> need SCTP and
> >>>shouldn't use anything else" which I think ignores some 
> practical matters
> >>>in terms of rapid implementation and adoption.
> >>
> >>The question posed (and remains the topic of discussion) is 
> "what should
> >>the default transport for IPFIX be"...  I read that as "if you MUST
> >>support only ONE transport, what should it be, given that we want
> >>congestion control and both reliable and unreliable export."
> >>
> >>Diameter essentially makes SCTP the default protocol (it shoud be
> >>tried first), and TCP the "fallback".  Servers are required 
> to support
> >>both.
> >>
> >> From RFC 3588:
> >>
> >>2.1.  Transport
> >>
> >>    Transport profile is defined in [AAATRANS].
> >>
> >>    The base Diameter protocol is run on port 3868 of both 
> TCP [TCP] and
> >>    SCTP [SCTP] transport protocols.
> >>
> >>    Diameter clients MUST support either TCP or SCTP, while 
> agents and
> >>    servers MUST support both.  Future versions of this 
> specification MAY
> >>    mandate that clients support SCTP.
> >>
> >>    [snip]
> >>
> >>    When connecting to a peer and either zero or more transports are
> >>    specified, SCTP SHOULD be tried first, followed by TCP. 
>  See Section
> >>    5.2 for more information on peer discovery.
> >>
> >>regards,
> >>--peter
> >>
> >>
> >>>Regards,
> >>>
> >>>  Jeff Meyer
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Robert Lowe [mailto:[email-masked]]
> >>>Sent: Monday, October 13, 2003 1:30 PM
> >>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> >>>Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; 
> [email-masked]';
> >>>[email-masked]; [email-masked]; 'Reinaldo Penno';
> >>>[email-masked]; [email-masked]
> >>>Subject: Re: [ipfix] STCP as a default transport not
> >>>
> >>>
> >>>MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> >>>
> >>>Hi Jeff!
> >>>
> >>>
> >>>
> >>>> By availability I mean you take the system out of the 
> box and w/in 5
> >>>>minutes
> >>>>of booting you are able to use the service.  TCP fits 
> this criteria.
> >>>>Perhaps
> >>>>that is also true for SCTP on IOS, I would presume given 
> your arguments.
> >>>>However on no other platform other than Linux am I aware of this
> >>>>availability.
> >>>>
> >>>> SCTP does not come preloaded on Windows, Solaris or 
> HP-UX, and if I go
> >>>
> >>>the
> >>>
> >>>
> >>>>the
> >>>>Microsoft, Sun and HP sites looking for infomration on 
> how to configure
> >>>>SCTP, I get
> >>>>either nothing or a reference to 3rd party (for fee) 
> products to enable
> >>>>this.
> >>>>
> >>>> So, although in your world this may still count as 
> "available".  In the
> >>>>world of delivering multiplatform capable packaged 
> collection SW which can
> >>>>be
> >>>>installed rapidly, it just don't cut it.
> >>>
> >>>
> >>>De-lurking again... ;-)
> >>>
> >>>I assume we're talking about collectors here, not 
> exporters.  Where do most
> >>>collectors run today?  Just a wild guess, but a majority 
> on Linux or moving
> >>>there?  I could be wrong though.
> >>>
> >>>Either way, you're providing the same argumentation that 
> you, and others,
> >>>didn't agree with regarding candidate protocols, i.e. 
> Netflow is more
> >>>widely implemented, making IPFIX more likely to be 
> implemented, therefore
> >>>better.  I mean, I can remember a day when Microsoft 
> didn't have their own
> >>>implementation of TCP/IP, and noone worried.  I'm not 
> advocating a "build
> >>>it and they will come" approach, but I also recognize that 
> solutions do not
> >>>always win out based solely on technical merit.  So are 
> you wrong?  Maybe
> >>>not, but as Carter suggests, it is important to ensure 
> that the transport
> >>>is not a hindrance to any of the other requirements.  So, 
> if I had any say,
> >>>I'd recommend focusing the discussion on any interactions 
> between any
> >>>proposed transport and other requirements, not overly 
> worrying about what
> >>>the landscape looks like today for both implementers and 
> end-customers,
> >>>other than perhaps architecture, which also has direct 
> bearing on how
> >>>exporter, collector, and any intervening network will 
> behave under stress.
> >>>
> >>>Over and out,
> >>>Robert
> >>>
> >>>--
> >>>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: Nevil Brownlee <[email-masked]>
Date: Wed, 15 Oct 2003 15:18:45 +1300

Hi all:

In an attempt to move the 'default transport' discussion forward a little,
can I have some feedback on my suggestion a day or two back, i.e. how
about this ..

  TCP  mandatory to implement   =  easy to make collectors

  SCTP optional                 =  equipment / flow collector developers
                                   can demonstrate advantages for users
                                   of IPFIX over SCTP

I suggested this because it seems to me that lots of people may develop
IPFIX collectors, wheras not too many will be developing exporters.

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/

---

From: Alex Audu <[email-masked]>
Date: Wed, 15 Oct 2003 09:28:38 -0500

Hi Jeffery,

I guess my point is I detect something that looks like a tendency to
miss-inform so as to make a point. If we are going to chose a protocol
to do a job, we chose it based soley on its technical merits. Arguments
like "Oh, SCTP is kernel space transport" is just not accurate. That
prompted
my response about my personal experience in implementing SCTP in user space.

And I don't see anything in the SCTP specs that says it must be in kernel
space.

The bottom line is SCTP is a better transport than TCP. Heck, it was
designed
to correct issues with TCP in the first place. If members of the technical
community don't reccomend it for deployment (because it is not widely
available), how is it ever going to be widely available?

Regards,
Alex.

---

From: Mark Fullmer <[email-masked]>
Date: Mon, 20 Oct 2003 11:27:13 -0400

How about if we skip the mandatory and optional section for now and
just specify TCP and SCTP.  This allows us to move forward with the
ID, implementations with both protocols can be developed, etc.

The decision on which protocol is mandatory should be based 
on working implementations, not speculation.

mark

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 20 Oct 2003 11:57:35 -0500

Mark:

I could live with that for now :>

It might be a way forward... Nevil?

R

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Oct 2003 13:24:30 -0500

> just specify TCP and SCTP.

the goal is for end users to be able to plug together prodcuts
from different vendors and have them interoperate.  without a
transport being known to be available, i.e., mandatory to
implement, please explain how this will work?

randy

---

From: Mark Fullmer <[email-masked]>
Date: Tue, 21 Oct 2003 13:12:22 -0400

Moving forward with TCP and SCTP/PR-SCTP in the ID will allow
the decision process for which one gets the "mandatory" tag to
have some input from running code.

I just don't think this is worth arguing about right now because
there are no IPFIX implementations.

mark

---

From: Robert Lowe <[email-masked]>
Date: Tue, 21 Oct 2003 13:00:45 -0500

> there are no IPFIX implementations.

And who will write one if something as basic as the default transport
hasn't been decided?  What's the use of having a standard without a
standard?  What good is it if I purchase a router from vendor X, a
probe from vendor Y, and a collector from vendor Z, and I can't make
them work together?  Avoiding a hard decision won't help anything.

-Robert

---

From: Mark Fullmer <[email-masked]>
Date: Tue, 21 Oct 2003 14:28:57 -0400

I'm not advocating avoiding the decision, just letting this rest
for a little while and moving the ID ahead with TCP and SCTP
defined.

mark

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 22 Oct 2003 14:53:22 -0500

Robert:

a quick little comment ... with code even :>

> them work together?  Avoiding a hard decision won't help anything.
As far as writting an actual collector goes aka TCP or SCTP(SCTP/PR) there
is really only one thing different:

sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
or
sd = socket(AF_INET,SOCK_STREAM, IPPROTO_SCTP);

thats it... from a collector standpoint. Since the collector is only
collecting/reading.. and will not be using any of the advanced features
of SCTP... it really is a one line change.

So I would hope a one line change would not stop a vendor..

I can point you to several web sites that have things like

apache
mozilla
ftp
and
the ssh suite

All that have made a one line change to do SCTP... well.. I guess I am
lying on mozilla it was actually 2 lines of code...

Now that being said, none of the above took advantage of any advance
features... but as I said, since the collector is not the source of the data
it will not effect how it collects if it is using TCP or SCTP..

R