Re: [ipfix] STCP as a default transport not

[Benoit Claise <[e-mail]>]

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
>
>
>
>
> -- 
> Help        mailto:[e-mail] and say "help" in 
> message body
> Unsubscribe mailto:[e-mail] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/