RE: [ipfix] STCP as a default transport not

["Carter Bullard" <[e-mail]>]

Hey Stewart,
The default transport for a standards track protocol should
at least be an RFC.  I'm not against having hooks to jumpstart
a PR-STCP association in IPFIX, but not as the default.  And
those hooks should come after the PR-STCP is described
as an RFC and has had some time to bake, and possibly more
important, after there is a working IPFIX to find out if you
even need its features.

As an internet draft its just an idea.

Carter


> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]]
> Sent: Tuesday, October 07, 2003 10:13 AM
> To: [e-mail]
> Cc: [e-mail]; 'Reinaldo Penno'; 'MEYER,JEFFREY D
> (HP-Cupertino,ex1)'; [e-mail];
> [e-mail]
> Subject: Re: [ipfix] STCP as a default transport not
>
>
>
> 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/