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

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 7 Oct 2003 08:11:50 -0700

I have a question in - multi-homing support. 

My original idea is that SCTP would bring value in reliability because a
exporter could make a connection to exporter A and if it finds that
connection has problems, switch to a totally separate collector B.

Reading the excerpt below, it seems SCTP can only make the failover when the
two interfaces are on the same device, i.e., under the control of the same
SCTP stack I guess.  

"This capability can be used to build redundant paths between two SCTP
endpoints....Achieving path redundancy between two SCTP endpoints normally
requires that the two endpoints being equipped with multiple interfaces
assigned with multiple addresses and that routing is configured
appropriately"

In this case it seems to me SCTP would not bring real value at least in
reliability) since the main concern is being able to switch from collector A
to collector B, where A and B are different devices altogether.

Could you clarify?

Thanks,

Reinaldo 

> -----Original Message-----
> From: Alex Audu [mailto:[email-masked]] 
> Sent: Tuesday, October 07, 2003 10:56 AM
> To: [email-masked]
> Cc: Penno, Reinaldo [BL60:SF30:EXCH]; 'MEYER,JEFFREY D 
> (HP-Cupertino,ex1)'; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [ipfix] STCP as a default transport not
> 
> 
> Hello Carter,
> 
> This excerpt from rfc 3257 indicates SCTP can be used in 
> place of TCP. Moreover, SCTP makes it easier to design a more 
> reliable system due to its multi-homing and multiple 
> streams-per-assoication features. This works well for a 
> redundant (carrier grade) IPFIX architecture.  Also, its 
> message oriented feature makes it easier for the application 
> to detect application message boundaries.
> 
> It would be appreciated if you could point out technical 
> reasons why SCTP is not a good solution for IPFIX. Otherwise, 
> I vote for SCTP for IPFIX.
> 
> Regards,
> Alex.
> 
> ====================================================
> 
> 2.2 SCTP service model
> 
>    SCTP is also connection-oriented and provides all the transport
>    services that TCP provides.  Many Internet applications therefore
>    should find that either TCP or SCTP will meet their transport
>    requirements.  Note, for applications conscious about processing
>    cost, there might be a difference in processing cost 
> associated with
>    running SCTP with only a single ordered stream and one address pair
>    in comparison to running TCP.
> 
>    However, SCTP has some additional capabilities that TCP lacks and
>    This can make SCTP a better choice for some applications and
>    environments:
> 
>    - multi-streams support:
> 
>    SCTP supports the delivery of multiple independent user message
>    streams within a single SCTP association.  This capability, when
>    properly used, can alleviate the so-called head-of-line-blocking
>    problem caused by the strict sequence delivery constraint 
> imposed to
>    the user data by TCP.
> 
>    This can be particularly useful for applications that need to
>    exchange multiple, logically separate message streams between two
>    endpoints.
> 
>    - multi-homing support:
> 
>    SCTP provides transparent support for communications between two
>    endpoints of which one or both is multi-homed.
> 
>    SCTP provides monitoring of the reachability of the 
> addresses on the
>    remote endpoint and in the case of failure can 
> transparently failover
>    from the primary address to an alternate address, without 
> upper layer
>    intervention.
> 
>    This capability can be used to build redundant paths 
> between two SCTP
>    endpoints and can be particularly useful for applications that seek
>    transport-level fault tolerance.
> 
>    Achieving path redundancy between two SCTP endpoints normally
>    requires that the two endpoints being equipped with multiple
>    interfaces assigned with multiple addresses and that routing is
>    configured appropriately (see Section 3).
> 
>    - preservation of message boundaries:
> 
>    SCTP preserves application messages boundaries.  This is 
> useful when
>    the application data is not a continuous byte stream but comes in
>    logical chunks that the receiver handles separately.
> 
>    In contrast, TCP offers a reliable data stream that has no 
> indication
>    of what an application may consider logical chunks of the data.
> 
>    - unordered reliable message delivery:
> 
>    SCTP supports the transportation of user messages that have no
>    application-specified order, yet need guaranteed reliable delivery.
> 
>    Applications that need to send un-ordered reliable 
> messages or prefer
>    using their own message sequencing and ordering mechanisms may find
>    this SCTP capability useful.
> 
> =====================================================
> 
> Carter Bullard wrote:
> 
> > I am emphatically against any mention of SCTP, unless someone can 
> > point out how the SCTP applicability statement, RFC 3257, 
> applies to 
> > IPFIX.
> >
> > Carter
> >
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Monday, October 06, 2003 11: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
> >
> > > -----Original Message-----
> > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
> [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]'
> > > Subject: RE: [ipfix] STCP as a default transport not
> > >
> > >
> > > 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: Alex Audu <[email-masked]>
Date: Tue, 07 Oct 2003 11:50:55 -0500

Hi Reinaldo,

Redundancy can be archieved in many ways. One simple way is to have a
"Collector box" containing mutiple collector processes. The collector
processes
may be running on different processors.

You can also have two different collector boxes (devices) on the same
network.
with different addresses, with one address being used by the Exporter.
What multi-homing provides is the ability for the Exporter to reach the
other collector
address if the default (collector) address is unreachable. Now, if you
mirror the two collectors with an internal link, then you have a
multi-homed network and a fully redundant system.

Of course, we are talking about implementation details. The key is SCTP
enables you to do this much more easily.  If you are collecting billing
information
with IPFIX, I think issues like this it become important.

Regards,
Alex.

Reinaldo Penno wrote:

> My original idea is that SCTP would bring value in reliability because
> a exporter could make a connection to exporter A and if it finds that
> Reading the excerpt below, it seems SCTP can only make the failover
> when the two interfaces are on the same device, i.e., under the
> control of the same SCTP stack I guess.
>
> endpoints....Achieving path redundancy between two SCTP endpoints
> normally requires that the two endpoints being equipped with multiple
> configured appropriately"
>
> In this case it seems to me SCTP would not bring real value at least
> in reliability) since the main concern is being able to switch from
> collector A to collector B, where A and B are different devices
> altogether.
>
> Could you clarify?
>
> Thanks,
>
> Reinaldo
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 08 Oct 2003 14:12:49 +0100

From the discussions on this thread, the selection of the
default transport clearly needs to be on the agenda for
Minneapolis.

The current agenda does not have IPFIX. Have the chairs
requested a meeting slot?

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/

---

From: Dave Plonka <[email-masked]>
Date: Wed, 8 Oct 2003 09:45:50 -0500

> default transport clearly needs to be on the agenda for

noted ;^)
 
> requested a meeting slot?

Yes, and it has AD approval.
We're just waiting for it to appear on the agenda.

Dave

-- 
"This is only temporary, unless it works."
 - Red Green

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 11 Oct 2003 18:29:10 -0500

> collector A to collector B, where A and B are different devices 
Reinaldo:

a comment or two..

While it is true that SCTP does NOT help with switching to collector A 
to collector B transparently.. it does
allow the failure to be controled in a MUCH more reasonalbe maner than 
TCP. Basically there
are knobs that you, the application designer, can tweak to set the 
failover detection time to what
you want it to be... this is something that is nearly impossible in most 
TCP stacks...

SCTP was designed with this sort of thing in mind ... tuneable to the 
applications failure detections
specific needs...

This can be a big win.. multi-homing also may be more of a help then you 
think.. if billing information
is being collected then you don't want an interface card failure to kill 
your association.. with SCTP
this is taken care of without the app getting involvoed... it may be 
that some may not need this.. but it
is a nice feeature to have for the app.. at no additional expense :>

R

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

---

From: Peter Ludemann <[email-masked]>
Date: Sun, 12 Oct 2003 20:54:32 -0700 (PDT)

--- "Randall Stewart (cisco)" <[email-masked]> wrote:

> While it is true that SCTP does NOT help with switching to
> collector A to collector B transparently.. it does
> allow the failure to be controled in a MUCH more reasonalbe
> maner than TCP. Basically there
> are knobs that you, the application designer, can tweak to
> set the failover detection time to what
> you want it to be... this is something that is nearly
> impossible in most TCP stacks...

Isn't this a property of the API, not of the protocol? It is
unfortunate that most (all?) TCP implementations do not give
access to the "tweak"ing at the application level, but
require global kernel parameter setting. The SCTP API
designer should be applauded for avoiding this mistake of the
TCP APIs.

I apologise if I am out of date on the SCTP implementations
-- I've looked at RFC 2960,
draft-ietf-tsvwg-sctpsocket-07.txt and
http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp-api.pdf
. Perhaps I missed something, but these seem to not give
APPLICATION-level confirmation of receipt of data, but only
communication-level confirmation. So, for full reliability,
IPFIX needs to have its own confirmation mechanism (the data
might have been received at the transport layer but the
application might have crashed before processing it); and
IPFIX/TCP can provide a fail-over mechanism as good as SCTP's
by using the application-level acknowledgment mechanism (by
the way, the application-level acknowledgment has very small
overhead, compared to TCP's/SCTP's).

I do agree that SCTP is a better protocol than TCP for IPFIX,
because of its message orientation and because of its better
support for fail-over. Nevertheless, it does not solve *all*
the issues for reliability and fail-over (or, rather, the
APIs that I have looked at do not solve the issues) and -- if
full reliability is desired -- the IPFIX protocol must have
its own features for filling in the missing pieces.

But this is just repeating old arguments that have been voted
down by those who don't need/want reliability. Perhaps what
is needed is a set of optional features for implementing a
fully reliable IPFIX for those who need it. The default
protocol for unreliable IPFIX might even be different than
for reliable IPFIX. And for unreliable IPFIX, TCP seems "good
enough" and more common than SCTP.