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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 2 Oct 2003 17:05:22 -0400

I'd be interested in knowing what the specific aspects of SCTP
are that the IPFIX protocol authors want to use, and how they
do or do not conflict in some way with a parallel mapping to TCP.

Taking the Diameter approach of specifying both TCP and SCTP 
would allow for the market to decide if ubiquity of availability
or the special capabilities of SCTP are more important.

-- Jeff

> -----Original Message-----
> From: Carter Bullard [mailto:[email-masked]]
> Sent: Thursday, October 02, 2003 1:00 PM
> To: [email-masked]
> Cc: [email-masked]; 'Reinaldo Penno';
> [email-masked]; [email-masked]
> Subject: RE: [ipfix] STCP as a default transport not
> 
> 
> Hey Alex,
>    Did I say something wrong?  I firmly believe that people adopt
> technology when it solves problems.  STCP will get around as
> its found to be a real solution.  But with regard to STCP and
> IPFIX, I read RFC 3257, the SCTP Applicability Statement, and
> I don't see where IPFIX fits.  Benefits of SCTP over TCP are:
> 
>    multi-streams support
>    multi-homing support
>    preservation of message boundaries
>    unordered reliable message delivery
> 
> The first three I don't see as requirements for IPFIX.
> I actually believe the last one to be a problem for IPFIX.
> STCP is less efficient that TCP, and so if IPFIX doesn't need
> any of these 4 items, then I don't see the applicability.
> 
> Carter
> 
> 
> > -----Original Message-----
> > From: Alex Audu [mailto:[email-masked]]
> > Sent: Thursday, October 02, 2003 2:51 PM
> > To: [email-masked]
> > Cc: [email-masked]; 'Reinaldo Penno';
> > [email-masked]; [email-masked]
> > Subject: Re: [ipfix] STCP as a default transport not
> >
> >
> > Hello Carter,
> >
> > If it is true that SCTP hasn't been widely deployed, it is
> > probably because
> > of statements like you have made below. Look, we all know SCTP has
> > a lot of benefits over TCP.  If folks like you don't drive
> > its deployement
> > by specifying it as default transport, how will it be
> > ubiquitous? It is a
> > self fulfilling prophesy.
> >
> > For IETF protocols that recommend SCTP as defaults, see rfc
> > 3057, rfc 3331
> > and rfc 3332 just to name a few.
> >
> > Regards,
> > Alex.
> >
> > Carter Bullard wrote:
> >
> > > I believe that SCTP-PR is not deployed widely enough
> > > to be considered a default for any IETF technology.
> > > It is not on my Linux RedHat 9.0 distribution, nor
> > > my Mac OS-X or my Windows XP system.  I don't see it
> > > available on any Solaris machine that I have access
> > > to.
> > >
> > > What IETF technology is currently using SCTP as a
> > > default transport?
> > >
> > > Carter
> > >
> > > > -----Original Message-----
> > > > From: majordomo listserver
> > > > [mailto:[email-masked]] On Behalf Of Stewart Bryant
> > > > Sent: Thursday, October 02, 2003 12:14 PM
> > > > To: Reinaldo Penno
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: [ipfix] Ipfix Protocol open items
> > > >
> > > >
> > > >
> > > >
> > > > Reinaldo Penno wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Have we zeroed in a certain transport protocol? TCP, 
> SCTP-PR or
> > > > > something else?
> > > > >
> > > > > I need to write something to explain how Netflow runs over
> > > > TCP, but it
> > > > > seems to me somewhat of a lower priority if this is not
> > > > going to be the
> > > > > default protocol. We should focus on explaning how this
> > > > should work on
> > > > > the "choosen one".
> > > >
> > > > I think that perhaps the question should be put another
> > way. There are
> > > > WG members who propose SCTP-PR as the default, and SCTP-PR has
> > > > advantage because of its better flexibility in coping
> > with congestion.
> > > >
> > > > So the real question is whether there are WG members who
> > think that
> > > > the default should be TCP. If no group comes forward, 
> then we have
> > > > our answer. If there is support then we need to perform 
> a detailed
> > > > analysis of the relative merits of the two protocols.
> > > >
> > > > Stewart
> > > >
> > > >
> > > > --
> > > > 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/
> >
> >
> 
> 
> 
> 
> --
> 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: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 8 Oct 2003 16:55:55 -0400

Hi,
 
  Does this mean UDP gets taken out?  Or will there be 3 bindings for
different environmental requirements? [That would be my suggestion]
 
o bindings over TCP for reliable communication while accomodating for  some
failover mechanism if the collector becomes congested or disabled; 

o bindings of UDP for best effort (i.e. no exporter back pressure) in
configurations where exporter and collector are colocated and congestion
aware behavior is not a concern; 

o binding of PR_SCTP where congestion aware behavior and best effort are
desired.

-- Jeff

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Monday, October 06, 2003 9:34 AM
To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [email-masked]';
[email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: RE: [ipfix] STCP as a default transport not

Okay... 

It seems we haven't reached a (firm) conclusion, but we need to get the
draft going and this is a big piece of it. Jeff seems to propose specifying
both (TCP and SCTP). Anyone opposes this? Or should we stick with one
protocol mapping?

We need to start converging on this really soon. 

Thanks, 

Reinaldo 

> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, October 02, 2003 5:05 PM 
> To: [email-masked]'; [email-masked]' 
> Cc: [email-masked]'; Penno, Reinaldo [BL60:SF30:EXCH]; 
> [email-masked]'; [email-masked]' 
> I'd be interested in knowing what the specific aspects of 
> SCTP are that the IPFIX protocol authors want to use, and how 
> they do or do not conflict in some way with a parallel mapping to TCP. 
> 
> would allow for the market to decide if ubiquity of 
> availability or the special capabilities of SCTP are more important. 
> 
> -- Jeff 
> 
> > From: Carter Bullard [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > technology when it solves problems.  STCP will get around 
> as its found 
> > to be a real solution.  But with regard to STCP and IPFIX, 
> I read RFC 
> > 3257, the SCTP Applicability Statement, and I don't see where IPFIX 
> > fits.  Benefits of SCTP over TCP are: 
> > 
> >    multi-streams support 
> >    multi-homing support 
> > I actually believe the last one to be a problem for IPFIX. STCP is 
> > less efficient that TCP, and so if IPFIX doesn't need any 
> of these 4 
> > items, then I don't see the applicability. 
> > 
> > Carter 
> > 
> > 
> > > From: Alex Audu [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > If it is true that SCTP hasn't been widely deployed, it 
> is probably 
> > > because of statements like you have made below. Look, we all know 
> > > SCTP has a lot of benefits over TCP.  If folks like you 
> don't drive 
> > > its deployement 
> > > For IETF protocols that recommend SCTP as defaults, see rfc 3057, 
> > > rfc 3331 and rfc 3332 just to name a few. 
> > > 
> > > Regards, 
> > > Alex. 
> > > 
> > > Carter Bullard wrote: 
> > > 
> available on 
> > > > any Solaris machine that I have access to. 
> > > > 
> [ mailto:[email-masked] <mailto:[email-masked]>
] 
> > > > > On Behalf Of Stewart Bryant 
> > > > > Help        mailto:[email-masked]
<mailto:[email-masked]>  and say "help" 
> > > > > in message body 
> > > > > Unsubscribe mailto:[email-masked]
<mailto:[email-masked]>  and say 
> > > > > Archive     http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>  
> > > > > 
> > > > 
> > > > -- 
> > > > Help        mailto:[email-masked]
<mailto:[email-masked]>  and say 
> > > "help" in message body 
> > > > Unsubscribe mailto:[email-masked]
<mailto:[email-masked]>  and say 
> > > > Archive     http://ipfix.doit.wisc.edu/archive/
<http://ipfix.doit.wisc.edu/archive/>  
> > > 
> > > 
> > 
> > 
> > 
> > 
> > -- 
> > Help        mailto:[email-masked]
<mailto:[email-masked]>  and say "help" 
> > in message body 
> > Unsubscribe mailto:[email-masked]
<mailto:[email-masked]>  and say "unsubscribe 
> > ipfix" in message body 
<http://ipfix.doit.wisc.edu/archive/>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 8 Oct 2003 14:11:45 -0700

The UDP binding was dropped a long time ago due to the fact that the
selected protocol needed to be congestion friendly. 
 
That's why SCTP-PR came to be. It can be unreliable, yet congestion aware. 

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 4:56 PM
To: Penno, Reinaldo [BL60:SF30:EXCH]; MEYER,JEFFREY D (HP-Cupertino,ex1);
[email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: RE: [ipfix] STCP as a default transport not

Hi,

-- Jeff

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Monday, October 06, 2003 9:34 AM
To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [email-masked]';
[email-masked]'

Okay... 

Thanks, 

Reinaldo 

> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[email-masked]
> > From: Carter Bullard [mailto:[email-masked]
> > > From: Alex Audu [mailto:[email-masked]
> [mailto:[email-masked] <mailto:[email-masked]> ]

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 9 Oct 2003 13:49:34 -0400

In the IPFIX space there are two aspects to congestion control.

As you cite, consuming an unfair percentage of resources is something
which TCP avoids and UDP does not.

However many Netflow deployments have switched direct connections
between the exporter and the collector.  I.e. there's nobody else's
traffic to damage.

At that point, congestion becomes an issue of whether the exporter
can "keep up" with the exporter.  The main concern I hear around
TCP/IP is that the stack will be sitting on unacknowledged packets
and ultimately apply back pressure to the exporter if the collector
slows down.

Not acknowledging that the UDP over dedicated connection is a common
and valid use case AND that in this use case, the "congestion aware"
aspect of fairness is a moot point is poor engineering.

-- Jeff

> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, October 09, 2003 10:23 AM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: 'Benoit Claise'; [email-masked]; [email-masked];
> [email-masked]; 'Reinaldo Penno'; [email-masked];
> [email-masked]; [email-masked]
> > Dropping packets under congestion is already done by UDP, and
> > UDP is ubiquitous in all OS's.
> 
> congestion control is not about you losing your data.  it is about
> your damaging the data of others.
> 
> randy
>

---

From: "Carter Bullard" <[email-masked]>
Date: Thu, 9 Oct 2003 13:58:17 -0400

I'm unhappy that the only apparent considerations are
connection oriented and unicast.  I'm going to use multicast
to move flow data in some situations, and at this point,
no candidate IPFIX transport is going to make it.

When I mentioned RTP earlier, I was not being facetious.
The IESG seems to think that RTP/UDP is not verboten,
from a congestion perspective, regardless of the speeds,
so I believe that that should be on a discussion list.

Carter

> Sent: Thursday, October 09, 2003 12:03 PM
> To: 'Benoit Claise'; [email-masked]
> Cc: [email-masked]; [email-masked]; 'Reinaldo
> Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1);
> [email-masked]; [email-masked]; [email-masked]
> Benoit,
>   SCTP-PR does not make me happy, nor do the previous decisions
> around reliability as it regards to billing.
>
>   Is there some challenge in defining IPFIX over TCP?  It seems
> to me that this is the easier case, there are less things to map
> to vs. SCTP-PR.  Is explicitly NOT defining a mapping to TCP
> your proposal, i.e. force the use of SCTP-PR?
>
>   As with the experience of Diameter, specifying both transports
> will enable a migration to SCTP-PR for everyone if it actually
> proves to have the values espoused and it is readily available.
> In the interim having a TCP mapping (and UDP) would address the
> requirements which I've encountered (billing issues aside).
>
>   As Peter pointed out the resource constraints on the exporter
> imposed by TCP can be mitigated in the implementation.
>
> Regards,
>
>   Jeff Meyer
>
> > From: Benoit Claise [mailto:[email-masked]]
> > Sent: Thursday, October 09, 2003 9:15 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; 'Reinaldo Penno';
> > 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
> [email-masked];
> > Dear all,
> > There are advantages regarding the use of SCTP versus TCP
> (discussed
> > already on the list) but I think that the biggest advantage
> > of SCTP is
> > actually the extension SCTP-PR. And I'm surprised to see no
> > reactions on
> > the email below.
> > Yes, I know that the SCTP-PR is not a standard yet but I
> > think that we
> > should just take the right protocol instead of just using
> what exists
> > because it exists!
> >
> > I remember the heated discussions maybe one year ago about
> > using IPFIX
> > for billing, about high availability, etc...
> > And one of the solution that could make everybody happy is: SCTP-PR.
> > We know that we do have some memory issues with TCP on the
> > high-end routers.
> > But, for the smaller exporter OR if you can afford/if it's
> > possible to
> > pack the exporter with the appropriate amount of  memory,
> > SCTP-PR would
> > work perfectly well!
> > Now, in the majority of cases (no billing, no enough
> memory/too many
> > flow records, etc...) SCTP-PR would drop the flow records
> > excess if any,
> > which I think is the right thing to do.
> >
> > Regards, Benoit.
> >
> >
> > >
> > > I think that the interest is in using PR-SCTP as described in
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt
> > >
> > > rather than RFC 2960 SCTP.
> > >
> > > This claims the following benefits:
> > >
> > >
> > > 1.3 Benefits of PR-SCTP
> > >
> > >    Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
> > >    protocol extended as defined in this document.
> > >
> > >    The following are some of the advantages for integrating
> > partially
> > >    reliable data service into SCTP, i.e., benefits of PR-SCTP:
> > >
> > >    1.  Some application layer protocols may benefit from
> > being able to
> > >        use a single SCTP association to carry both reliable
> > content, --
> > >        such as text pages, billing and accounting
> information, setup
> > >        signaling -- and unreliable content, e.g. state that
> > is highly
> > >        sensitive to timeliness, where generating a new
> > packet is more
> > >        advantageous than transmitting an old one [1].
> > >
> > >    2.  Partially reliable data traffic carried by PR-SCTP
> > will enjoy the
> > >        same communication failure detection and protection
> > capabilities
> > >        as the normal reliable SCTP data traffic does. This
> > includes the
> > >        ability to: - quickly detect a failed destination
> address; -
> > >        fail-over to an alternate destination address, and;
> > - be notified
> > >        if the data receiver becomes unreachable.
> > >
> > >    3.  In addition to providing unordered unreliable data
> > transfer as
> > >        UDP does, PR-SCTP can provide ordered unreliable
> > data transfer
> > >        service.
> > >
> > >    4.  PR-SCTP employs the same congestion control and congestion
> > >        avoidance for all data traffic, whether reliable
> or partially
> > >        reliable  - this is very desirable since SCTP enforces
> > >        TCP-friendliness (unlike UDP.)
> > >
> > >    5.  Because of the chunk bundling function of SCTP,
> reliable and
> > >        unreliable messages can be multiplexed over a
> single PR-SCTP
> > >        association.  Therefore, the number of IP datagrams
> > (and hence
> > >        the network overhead) can be reduced versus having
> > to send these
> > >        different types of data using separate protocols.
> > Additionally,
> > >        this multiplexing allows for port savings versus
> > using different
> > >        ports for reliable and unreliable connections.
> > >
> > > ----------
> > >
> > > PR-SCTP has the option of being able to configure the
> > exporter to work
> > > on a
> > > best effort data export basis, rather than being
> > constrained to work on a
> > > reliable basis.
> > >
> > > We should spend some time thinking about the behaviour we
> > want in the
> > > exporter when the network is congested, perhaps due to an
> > attack. PR-SCTP
> > > gives us the option of running a best effort data
> > collection to gleen
> > > what
> > > is going on, when a TCP based exporter would otherwise
> > collapse due to
> > > backlog on the exporter.
> > >
> > > Stewart
> > >
> > >
> > >
> > >
> > > --

---

From: Peter Lei <[email-masked]>
Date: Thu, 09 Oct 2003 13:29:57 -0500

I don't really understand this UDP thread... I thought that it
was essentially "mandated" that the transport protocol used MUST
be congestion aware.  That ruled UDP out long ago, no??  Or is
that going to be debated again?!

I didn't see anyone point this out yet, but PR-SCTP is not just
"best effort" w/congestion control... it is an extension to SCTP
such that you can do any reliability level from best effort
(UDP-like) to fully reliable (SCTP or TCP like), and anywhere in
between.

So with SCTP and the PR-SCTP extension as transport, you can do
both the reliable and unreliable export with the same transport
stack... and it's all congestion controlled.  The application
layer decides what reliability needed when it does the send()
call.

The PR-SCTP draft has completed working group review and last
call in tsvwg and is supposed to be under IESG review right now.
If you look at the draft, it is a very straightforward and
"simple" extenstion to SCTP.

regards,
--peter

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Thu, 9 Oct 2003 15:09:10 -0400

Hi,

  I'm guessing the RTP/UDP waiver is due to some expectation that
RTP streams in applications such as voice and video have some 
upper bound on their consumption of resources.  E.g. a fixed 
500Kb/sec pump.

  In the case of Netflow, there are no guarantees of what the 
upper bound may be.  The whole point of the discussion seems 
centered around the inability of the exporter to handle back 
pressure.  So things like the RTP control protocol for reporting
observed dropped rates etc. wouldn't really help.  Or maybe
I'm missing something.

  But hey, if all it takes is slapping 12 bytes on the front of
the IPFIX packet to make it allowable, I'm all for it!

-- Jeff

> Sent: Thursday, October 09, 2003 10:58 AM
> To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise';
> [email-masked]
> Cc: [email-masked]; 'Reinaldo Penno';

---

From: "Carter Bullard" <[email-masked]>
Date: Thu, 9 Oct 2003 15:15:34 -0400

Hey Jeff,
   Well RTP/UDP is the protocol for handling video, like SMPTE 292M
and compressed HDTV (RFC 3497), so it has to be ok to go to minimally,
what is it, 1.485 Gbps.

Carter

> Sent: Thursday, October 09, 2003 2:09 PM
> To: [email-masked]'; MEYER,JEFFREY D (HP-Cupertino,ex1);
> 'Benoit Claise'; [email-masked]
> > > > > Help        mailto:[email-masked] and
> say "help" in
> > > > > message body

---

From: Stas Khirman <[email-masked]>
Date: Thu, 9 Oct 2003 14:48:55 -0700

Gentlemen,

Citing my extensive RTP/RTCP experience, I can't resist not to give my 2c to
your heated discussion. Sorry......

RTP/RTCP is designed for multimedia streaming applications, where timely
delivery of the information is significantly more important then its
completeness. Indeed, due human perception capabilities, you can lost a few
percent of voice packet without noticing any quality degradation. Video
information is even more "lost-sustainable". On the other hand, late
multimedia packet is not different from the lost one . As a result, it's
assumed than multimedia streaming application will NOT resend lost frame -
anyway, it will arrive to late (partial exception for prerecorded
video-on-demand applications with a big sender-based buffer).

Initially, RTP (data) channel is used to send a multimedia frames ( packets)
with some predefined rate. RTCP (control or feedback) channel is used to
inform sender about quality of information delivery. Certainly, it includes
lost packet ratio, but often inter-packet-delivery jitter is considered as a
more sensitive parameter. RTCP information may be used ( or have to be used,
if you expect quality) to "adapt" sender application, often by scaling
quality/bandwidth codacs parameters ( or replacing codacs on the fly).

RTP/RTCP itself has neither rate control, nor congestion avoidance and
retransmission functionalities build-in - all these features are left for an
application.

There are a few interesting RTP extension to support a [semi-]reliable
multicast, but I didn't see anything working outside university projects (
my info may be 2-3 years outdated - any corrections are welcome).

Considering said above, I do NOT recommend to use RTP/RTCP as a basis for
IPFIX - its belongs to totally different domain with [often] different
requirements and basic assumptions.

regards
Stas Khirman

> Sent: Thursday, October 09, 2003 12:09 PM
> To: [email-masked]'; MEYER,JEFFREY D (HP-Cupertino,ex1); 'Benoit
> Claise'; [email-masked]

---

From: "Carter Bullard" <[email-masked]>
Date: Thu, 9 Oct 2003 19:39:15 -0400

Hey Stas,
   I'm not advocating RTP/UDP as the basis of IPFIX,
just one of the transports available.  The reasoning
is two fold.  The first, many IP flow monitors today
use simple UDP.  RTP/RTCP would be a simple addition for
these devices in order for them to get some congestion
awareness, which is all the IESG is asking for.  I can't
think of any other IETF standard protocol more perfect
for these applications, since the modification for
these devices would/could be trivial compared to
converting to a connection-oriented strategy.

   The second, when building very high speed flow monitors
to support a specific class of network monitoring
applications, the transport goals are not any different
than those of streaming video. No need to go back, we do
want to know if there is loss and if there is toooo much
loss maybe do something drastic, and we'd like the other side
to be a bit adaptive, but basically just keep it coming.
RTP/RTCP seems ideal for that.

   When RTP was in its infancy, the discussion was that
it was the go to protocol if you wanted something in-between
TCP and UDP.  Signaling and control are out-of-band so
you get all the benefits of a pure connection-less protocol,
but you can get feedback if you want it.  Did that change
somewhere along the way?

Carter

> [mailto:[email-masked]] On Behalf Of Stas Khirman
> Sent: Thursday, October 09, 2003 4:49 PM
> To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
> [email-masked]'; 'Benoit Claise'; [email-masked]

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 10 Oct 2003 10:45:37 -0400

Benoit,

  I am not in any way against specifying IPFIX on top of PR-SCTP,
what I am against is making that the ONLY supported transport.
This is for practical reasons, like availability of implementation.
And as cited before because of transport protocols' affinity
for running in kernel vs. user space, the availability is going
to be a lot slower coming than one might like.

  I would liken this to deciding to define a transport layer
protocol which could only run on IPv6 and not IPv4.  You could,
but if you can run on both, I think there are decided benefits.

  The Diameter authors seemed to have made this pragmatic choice.

  It is a bit ironic that previous decisions of the WG around
choice of candidate protocols were ultimately trumped by "practical
reasons" like NF is more widely deployed, despite the fact
that it was the only protocol with NO binding to a congestion
aware transport.  And now, the arguments seem to be a complete
180 change.

Regards,

  Jeff Meyer

> Sent: Friday, October 10, 2003 3:26 AM
> Cc: [email-masked]; [email-masked]; [email-masked];
> 'Reinaldo Penno'; [email-masked];
> Jeff,
> My point is that I'm convinced that SCTP-PR gives all the advantages 
> in one transport protocol. See the recent postings from Peter 
> Lei; he knows the protocol a lot 
> better than I do!
> Having the full flexibility (reliable, unreliable, partially 
> reliable) in one transport protocol would be a plus. 
> Let's give the flexibility to the different implementations.
> On the top of that, we don't know yet the future applications 
> of IPFIX: 
> PSAMP is one, exporting SLA information?, some MIB variables 
> export?, etc... everything is possible since IPFIX is a generic 
> export format. 
> As I said, I think we should just use the right protocol 
> instead of just 
> using what exists. IMHO, SCTP_PR should be the target as transport 
> transport. So, I would vote for SCTP with the PR extension.
> 
> Regards, Benoit.
> 
> 
> >Benoit,
> >
> >>>       ability to: - quickly detect a failed destination address; -
> >>>       avoidance for all data traffic, whether reliable or 
> partially
> >>>   5.  Because of the chunk bundling function of SCTP, reliable and
> >>>       unreliable messages can be multiplexed over a single PR-SCTP

---

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 10 Oct 2003 13:42:03 -0400

Randy,

  Thanks for the pointer.  RFC 2309 seems like some well reasoned arguments
against UDP traffic which is travelling through routers in the internet,
or utilizing "shared links".

  Certainly some applications of IPFIX would follow this profile, so 
clearly UDP is NOT sufficient.

  However, in a situation where a middlebox has multiple ports and a
collection system has a direct wired connection to such a port  
on this device, it would seem the behavior cited in the RFC is irrelevant.

  Just so I'm clear, is the intent that all references to mapping the
protocol messages defined in IPFIX to UDP be expunged?  I.e. take 
away something which currently serves a broad community of users?

  Perhaps we should add the following wording to the protocol spec:

     Although this protocol was designed initially to run on UDP
     and the message set maps well to this transport;  and although
     it may be tempting to use this in certain controlled environments
     for which RFC 2309 has no bearing; an implementation SHALL NOT use 
     UDP.

  That would capture the arguments I've seen to date, and we can 
move on...

  Combine this with a strict mapping to PR-SCTP, and disallow TCP,
and you have the perfect paper spec that will address an extremely
narrow audience!

Regards,

  Jeff Meyer

> Sent: Thursday, October 09, 2003 12:15 PM
> Cc: [email-masked]
> > I'm sorry, perhaps I missed the well reasoned argument against the
> > use of UDP on point to point connections?
> > 
> > Could you direct me to that.
> 
> http://ipfx.doit.wisc.edu/list/ipfix/archive/
> 
> and you may want to review RFC 2309, particularly section 4
> 
> randy
>

---

From: "Carter Bullard" <[email-masked]>
Date: Sun, 12 Oct 2003 22:31:41 -0400

Hey Randall,
   In my systems, no one loses any records.  I don't rely on the
transport mechanism to provide reliability.

   My point was that on the wire congestion is rarely the problem
with high performance IPFIX style systems.  Its primarily
receiver resource issues.  I don't expect, nor do I want, the
transport layer to attempt to solve this type of problem.

Carter

> From: Randall Stewart (cisco) [mailto:[email-masked]]
> Sent: Saturday, October 11, 2003 6:43 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 'Reinaldo
> Penno'; 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
> >Hey Stewart,
> >>We should spend some time thinking about the behavior we want in the
> >>gives us the option of running a best effort data collection
> >>to gleen what
> >This is a real engineering issue to talk about.  Issues in
> producer/consumer
> >dynamics are real problems for IPFIX, especially when the flow record
> >source is generating 1M records per second, which my probes
> are capable
> >of doing.  In my experience, the reader/collector not keeping up is
> >never a network congestion problem, it is almost always a
> reader/collector
> >resource problem, slow disks, not enough memory, competing processes,
> >whatever.  It happens in SMP multi-threaded environments
> where the flow
> >generator and its collector are on the same machine, it
> happens when the
> >consumer is on the other end of a dedicated ATM, hyper-channel or
> >infiniband links.  Its not an issue of reliable vs
> unreliable transport,
> >its more an issue of what does the probe do when it finds it
> has 1M records
> >that aren't being consumed, and another 1M records are
> coming very soon.
> >Does it store them, drop them with an indication?  Does it
> proactively seek
> >an alternate association, the same association or does it
> wait for the
> >multiple readers to come back when they are ready.  Are
> there going to be
> >multiple readers?
> >
> >Usually the monitor is being attacked, or its generating
> twice the load
> >because something else is being attacked in the network.  No
> congestion,
> >just a lot of records.  I don't think PR-SCTP touches these problems.
> >
> >
> >
> Well, I disagree here.. PR-SCTP has the ability to detect the
> reader is not
> reading.. i.e. its flow-controlled the sender. When this
> occurs the sender
> can start dumping records that are marked to dump... yes
> tragic that you
> loose these records.. but necessary in the situation you
> define.. thus
> you get
> a double win:
>
> 1) You don't clog the network with the traffic since you are
> dumping it at
>     the sender
> 2) The receiver will have less to do since it will not get the traffic
> 3) You can set things up to get the last bits so you know the things
>      that started the problem.. or if you desire you can set things
>     up to get the last events jettising the older things....
>
> I think it will provide just what you want... at least to protect the
> network.. and then
> if everything is going ok (i.e. no floods or problems) you
> get all the
> records with no
> errors or drops..
>
> R
>
> >If you want the record generator to have a proactive role in
> >failover and recover, maybe RTP/RTCP would be a better choice.
> >Explicit feedback control channel provides enough to decide if
> >it should fail over.
> >
> >Carter
> >
> >
> >
> >>Stewart
> >>
> >>
> >>
> >>
> >>--
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
>
>

---

From: "Carter Bullard" <[email-masked]>
Date: Sun, 12 Oct 2003 22:56:31 -0400

Hey Randall,
   The paper is just one data point in my position that
PR-SCTP is a new protocol, and probably too new to be
the default and sole transport protocol for IPFIX.

   The proposal is to use PR-SCTP and you yourself stated
that its just Cisco and HP for commercial vendors and 2
universities.  HP is the only newcomer to bring PR-SCTP
to a bakeoff in 2003, and the story is still 'its our
intention to do PR-SCTP' for everyone else.  That was the
20 or so vendors/university's position position in 2002.
I'm now even more concerned that its taking some of these
vendors 2 years to do PR-SCTP.  And since you have no status
on Sun, which I believe is a most telling statistic, I'm a
bit more dubious about the extent of PR-SCTP's deployment.

   Lets just implement Netflow over PR-SCTP and lets see how
it goes for a while before everyone decides to make it the
default transport protocol.  A demonstration doesn't sound
too far fetched, does it?

   And of course if anyone could please apply the SCTP
applicability RFC to IPFIX, then that would go a long way.
I didn't know that IPFIX needed message boundary
preservation.  I don't even know what an IPFIX message
boundary looks like.

Carter

> Sent: Saturday, October 11, 2003 7:15 PM
> To: [email-masked]
> Cc: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise';
> [email-masked]; [email-masked]; 'Reinaldo Penno';
> Carter:
> The paper you site.. and yes I am on it.. was the basis
> we used to make sure "newreno" behavior for fast retransmit
> was put into the SCTP implementors guide. Now most implementations
> already were doing this (at least those I have talked to)...
>
> And as it is I don't think you will find true NewReno behavior
> in ALL TCP implementations either :-< So I guess by this
> reasoning TCP is also immature :-D
>
> SCTP is a VERY stable protocol that has a LOT of
> implementations (over
> 20 that I
> know of... probably close to 30 if I took the time to count
> them :>). Is
> there more
> research to do.. of course there is.. the same can be said for TCP..
> thats why
> the TSVWG exists ..we are always trying to make things better :>
>
> R
>
> Carter Bullard wrote:
>
> >My principal concern is that SCTP is too young to be the
> only transport.
> >For example, a recent Univ. of Delaware Technical Document,
> co-authored
> >by Cisco, identifies a serious problem with SCTP congestion control
> >when there are multiple drops in a single window, causing it
> to degrade
> >"more than necessary to be 'TCP-friendly', i.e. it grinds to
> a dribble
> >for a little while, while transmitting more packets.  The link where
> >you can get the publication is:
> >
> >http://www.eecis.udel.edu/~amer/PEL/poc/index.html
> >
> >The paper is "SCTP and TCP Variants: Congestion Control
> Under Multiple
> >Losses", very recent.  The point is that these are the normal growing
> >pains of a new protocol, but SCTP and PR-SCTP still have
> some problems
> >to iron out.
> >
> >Like Jeff, I have no problems with IPFIX running over PR-SCTP, but
> >not as the only protocol.
> >
> >Carter
> >
> >
> >
> >
> >
> >
> >>Sent: Friday, October 10, 2003 9:46 AM
> >>To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1)
> >>Cc: [email-masked]; [email-masked];
> >>[email-masked]; 'Reinaldo Penno';
> >>>My point is that I'm convinced that SCTP-PR gives all the
> >>>
> >>>
> >>advantages
> >>
> >>
> >>>>>And one of the solution that could make everybody happy
> >>>>>
> >>>>>
> >>is: SCTP-PR.
> >>
> >>

---

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

Randall,

  When you ask "Why wouldn't I take the best of both worlds w/ SCTP",
I think you are missing the point.

  I am perfectly fine with defining a binding on top of SCTP.  What I
don't want is for that to be the only defined binding.  The reasons
are based on the practical availability of SCTP to customers on both
new and existing systems.  TCP and UDP are there already, to use SCTP
in many situations will produce a lousy customer experience, especially
when being loaded on an existing system.

  Is there some particular reason why a binding to TCP (and UDP) in
addition to PR-SCTP is infeasable?  Here you get the tecnical elegance
of PR-SCTP for all to see and the ability to allow others to make
use of legacy platforms which may have prohibitive factors against
the use of SCTP?

-- Jeff

-----Original Message-----
From: Randall Stewart (cisco) [mailto:[email-masked]]
Sent: Saturday, October 11, 2003 4:54 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked]

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

>Hi,
>
>  I guess there is a concern of whether we are approaching this from
>the "optimize for the usual case" or "optimize for the worst case".
>
>  The former is usually preferred.
>
>  The general concern seems to be appropriate "capacity" on the 
>collector side so that little to no back pressure occurs on the
>sender.
>
>  UDP's fire and forget model makes this trivial, but its lack of
>congestion aware behavior is apparently a no no.  From the discussion
>it sounds like PR_SCTP has similar properties on overflow, where
>things just get tossed, like the behavior of the input UDP socket
>buffer when the collector is falling behind.
>
>  However, in a mode where the collector is sufficiently endowed
>to consume over TCP, which would hopefully be the majority of
>situations, taking advantage of TCP's ubiquity and reliability
>properties makes a lot of sense to me.
>
>  I'm still dubious of whether disallowing UDP (which happens to 
>be the only current concrete binding of NFv9) in favor of SCTP-PR
>is really the best approach.
>
>  Personally I'd recommend:
>
>     o bindings over TCP for reliable communication while accomodating for 
>       some failover mechanism if the collector becomes congested or
>disabled; 
>       configurations where exporter and collector are coresident and
>congestion 
Jeff:

But you miss a big point in this... Why not

o bind over SCTP for the reliabile data
o and send PR-SCTP for the case where you have records you are
   willing to give up in the crisis

SCTP in combination with PR-SCTP will:

1) Deliver all reliable information for you JUST LIKE TCP
2) During normal times all the records you are prepared to drop in
     a distress situation will get across TOTALLY reliably.
3) When you hit the rare situation .. the sender will begin to drop
     protecting your network..

So why would you not take the best of both worlds.. which is what SCTP 
can offer
you with PR-SCTP... they work on the same association..

R

>>From: Stewart Bryant [mailto:[email-masked]]
>>Sent: Wednesday, October 08, 2003 6:09 AM
>>To: [email-masked]
>>Cc: [email-masked]; 'Reinaldo Penno'; 'MEYER,JEFFREY D
>>(HP-Cupertino,ex1)'; [email-masked];
>>[email-masked]
>>>dynamics are real problems for IPFIX, especially when the 
>>>      
>>>
>>flow record
>>    
>>
>>>resource problem, slow disks, not enough memory, competing 
>>>      
>>>
>>processes,
>>    
>>
>>>whatever.  
>>>      
>>>
>>The critical issue is which side of TCP does it occur. If TCP 
>>has accepted
>>the data then the collector application had better do some 
>>intelligent.
>>My concern is with the exporter or probe having a backlog for 
>>any reason.
>>
>>    
>>
>>>It happens in SMP multi-threaded environments where the flow
>>>its more an issue of what does the probe do when it finds 
>>>      
>>>
>>it has 1M records
>>    
>>
>>On this point we absolutely agree.
>>
>>    
>>
>>>Does it store them, drop them with an indication?  
>>>      
>>>
>>I think that we have to assume that it does not have the storage.
>>
>> From the PR_SCTP draft:
>>
>>    One example of partially reliable service is specified in this
>>    document, namely a "timed reliability" service.  This 
>>service allows
>>    the service user to indicate a limit on the duration of 
>>time that the
>>    sender should try to transmit/retransmit the message (this is a
>>    natural extension of the "lifetime" parameter already in the base
>>    protocol).
>>
>>This seems to have the right properties
>>
>>    
>>
>>>Does it proactively seek
>>>because something else is being attacked in the network.  
>>>      
>>>
>>No congestion,
>>    
>>
>>>just a lot of records.  
>>>      
>>>
>>Anything that means that the exporter has a bunch of data wedged in
>>its output queues waiting for an ACK looks like congestion to 
>>the exporter.
>>
>>    
>>
>>>I don't think PR-SCTP touches these problems.
>>>
>>As I recall RTP requires the application to define its own approach to
>>congestion, and we do have to have a congestion strategy. It would
>>be better to use a congestion aware transport that has a build-in
>>strategy to bail-out if there is a problem, and PR-SCTP has just those
>>properties.
>>
>>Stewart
>>
>>
>>    
>>
>>>Carter
>>>
>>>
>>>      
>>>
>>>>Stewart
>>>>
>>>>
>>>>
>>>>
>>>>--

---

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

Peter,

  Here's what I meant by my statement:

  In general it is easier to develop and deliver user space applications,
vs.
kernel modules.  Things like portability of code, installation procedures,
impact of bugs are more signficant issues in kernel space.

  SCTP, like UDP and TCP is best suited as an OS service, although one could
develop an entirely user space application over raw IP sockets, but it would
have limitations like easily sharing SCTP services across multiple
processes.

  The SCTP API is simply the way a user space process makes use of the
kernel module enabling SCTP.

  Consider the quandry of a SW developer wanting to build a shiny new
IPFIX compliant offering on a variety of platforms.  Java would sure make
that handy, but there is no SCTP API binding for Java.  Writing in C/C++ 
allows you to use the SCTP API, but you still require the SCTP stack.
This isn't available preinstalled on platforms other than Linux that I
know of.  HP, Sun and Microsoft don't appear to be offering easy downloads
to
turn this on, so you are forced to either roll your own (e.g. hire a
different
set of developers) or to partner with some SCTP provider and inflate the
price of your offering.

  Now for the SIGTRAN type applications which were initially targeted by
SCTP, I can imagine that this premium is acceptable, after all the
alternative
was even more costly and complex IN/SS7 equipment and stacks.  For IPFIX
this is not the current state of affairs.

-- Jeff

-----Original Message-----
From: Peter Lei [mailto:[email-masked]]
Sent: Monday, October 13, 2003 3:22 PM
To: MEYER,JEFFREY D (HP-Cupertino,ex1)
Cc: 'Robert Lowe'; '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

> 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

> From: Robert Lowe [mailto:[email-masked]]
> Sent: Monday, October 13, 2003 1:30 PM
> Cc: 'Randall Stewart (cisco)'; 'Benoit Claise'; [email-masked]';
> [email-masked]; [email-masked]; 'Reinaldo Penno';
> 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
> 
> --

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 17 Oct 2003 11:11:45 -0400

Hey Alex,
I don't think anyone on the list thinks that IPFIX shouldn't
be able to use SCTP.  But SCTP as the default, or SCTP as the
only transport protocol?  I think there is a lot of enthusiasm
behind the sell job, but its more like a Chia pet ad than
an engineering effort.  Just add water, it will be beautiful.

An engineering effort would take the SCTP applicability RFC
and apply it to the IPFIX requirements to see that there is
a fit.  No one has done that!!!!

That is how you chose a protocol to do a job!

Time will tell if SCTP becomes the preferred transport for IPFIX,
but without a real demonstration that includes an implementation
of IPFIX over SCTP in a commercial router/switch, having the IPFIX
working group specify the current standard of practice for IPFIX
technology is not a bad idea.

Carter

> [mailto:[email-masked]] On Behalf Of Alex Audu
> Sent: Wednesday, October 15, 2003 9:29 AM
> Cc: 'Peter Lei'; 'Robert Lowe'; 'Randall Stewart (cisco)';
> 'Benoit Claise'; [email-masked]'; [email-masked];
> 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
> >
> > > Sent: Tuesday, October 14, 2003 3:13 PM
> > > Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'Robert Lowe';
> > > 'Randall Stewart
> > > (cisco)'; 'Benoit Claise'; [email-masked]';
> [email-masked];
> > > 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 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
> > > >>>it and they will come" approach, but I also recognize that
> > > solutions do not
> > > >>>is not a hindrance to any of the other requirements.  So,
> > > if I had any say,