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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 13 Oct 2003 17:23:27 -0400

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.

  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).

  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.

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/

---

From: Peter Lei <[email-masked]>
Date: Mon, 13 Oct 2003 17:21:50 -0500

> (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).

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

> 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

---

From: Alex Audu <[email-masked]>
Date: Tue, 14 Oct 2003 16:29:22 -0500

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.

TCP has been deployed both in user and kernel spaces and our in-house
SCTP was deployed in user space.

Regards
Alex.

---

From: Peter Lei <[email-masked]>
Date: Tue, 14 Oct 2003 17:12:42 -0500

> 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