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

From: "Carter Bullard" <[email-masked]>
Date: Mon, 6 Oct 2003 13:29:54 -0400

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 09:55:40 -0500

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.

=====================================================

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 07 Oct 2003 16:12:43 +0100

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: Benoit Claise <[email-masked]>
Date: Thu, 09 Oct 2003 18:15:01 +0200

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.