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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 15 Oct 2003 08:10:36 -0700

Alex,

  I'm not trying to misinform.  It certainly appears that the designers
of SCTP have addressed some sticky issues with TCP and UDP.

  However this is the IPFIX working group, not the SCTP advocacy working
group.  I believe part of an IETF's group's role is to produce a spec
which can be widely utilized quickly.  To that end, I see the mandatory
requirement of SCTP as being an issue.

-- Jeff

> -----Original Message-----
> From: Alex Audu [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2003 7:29 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'Peter Lei'; '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
> 
> 
> 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.
> 
> "MEYER,JEFFREY D (HP-Cupertino,ex1)" wrote:
> 
> > 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: Alex Audu <[email-masked]>
Date: Wed, 15 Oct 2003 10:31:14 -0500

Jeff,

And I agree, as far as drive for "quick utilization" doesn't lead to a less
effective and less robust solution. And by the way, neither is the IPFIX
group the advocacy group for TCP.

Regards,
Alex.