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

From: "Carter Bullard" <[email-masked]>
Date: Tue, 7 Oct 2003 11:34:02 -0400

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:[email-masked]]
> Sent: Tuesday, October 07, 2003 10:13 AM
> To: [email-masked]
> Cc: [email-masked]; 'Reinaldo Penno'; 'MEYER,JEFFREY D
> (HP-Cupertino,ex1)'; [email-masked];
> [email-masked]
> 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:[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: Stewart Bryant <[email-masked]>
Date: Wed, 08 Oct 2003 13:28:48 +0100

Carter Bullard wrote:
> at least be an RFC.  

No. The transport needs to be the right transport for the job.
If IPFIX has to wait in some intrim state, whilst the transport
also gains standards status, then so be it. This waiting does
not stop the deployment of IPFIX with some intrim status.

Stewart

---

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

Carter:

Long before you get IPFIX into RFC PR-SCTP WILL be an RFC. It finished
TSVWG last call quite some time ago.. and I have just recently 
corresponded with
Jon Peterson (Chair of TSV and AD in transport).. he stated to me:

>It will go to IESG last call
>as soon as the AD review phase is complete. There are a few matters related
>to this draft on which Allison and I still need to confer. I apologize for
>the delay, and I anticipate that the draft will advance to IETF last call
>shortly.
>
>  
>
So unless you can get all of IPFIX finished in the next say.. three 
months or so I don't
see how you could beat PR-SCTP to RFC status.

Now as far as working implementations... In June at the bakeoff we had
four interoperable implementations... and most of the others present 
planned on
testing PR-SCTP at the next bakeoff (which will occur sometime early in 
2004)

Regards

R

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