Re: [ipfix] STCP as a default transport not

["Randall Stewart (cisco)" <[e-mail]>]

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

Carter Bullard wrote:

>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/
>
>  
>


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



--
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/