Re: [ipfix] STCP as a default transport not

[Benoit Claise <[e-mail]>]

Jeff,

My point is that I'm convinced that SCTP-PR gives all the advantages 
in one transport protocol. See the recent postings from Peter Lei; he knows the protocol a lot 
better than I do!
Having the full flexibility (reliable, unreliable, partially reliable) in one transport protocol would be a plus. 
Let's give the flexibility to the different implementations.
On the top of that, we don't know yet the future applications of IPFIX: 
PSAMP is one, exporting SLA information?, some MIB variables export?, etc... everything is possible since IPFIX is a generic 
export format. 
As I said, I think we should just use the right protocol instead of just 
using what exists. IMHO, SCTP_PR should be the target as transport 
transport. So, I would vote for SCTP with the PR extension.

Regards, Benoit.


>Benoit,
>
>  SCTP-PR does not make me happy, nor do the previous decisions
>around reliability as it regards to billing.
>
>  Dropping packets under congestion is already done by UDP, and
>UDP is ubiquitous in all OS's.
>
>  Is there some challenge in defining IPFIX over TCP?  It seems
>to me that this is the easier case, there are less things to map
>to vs. SCTP-PR.  Is explicitly NOT defining a mapping to TCP 
>your proposal, i.e. force the use of SCTP-PR?
>
>  As with the experience of Diameter, specifying both transports
>will enable a migration to SCTP-PR for everyone if it actually
>proves to have the values espoused and it is readily available.
>In the interim having a TCP mapping (and UDP) would address the
>requirements which I've encountered (billing issues aside).
>
>  As Peter pointed out the resource constraints on the exporter
>imposed by TCP can be mitigated in the implementation.
>
>Regards,
>
>  Jeff Meyer
>
>  
>
>>-----Original Message-----
>>From: Benoit Claise [mailto:[e-mail]]
>>Sent: Thursday, October 09, 2003 9:15 AM
>>To: [e-mail]
>>Cc: [e-mail]; [e-mail]; 'Reinaldo Penno';
>>'MEYER,JEFFREY D (HP-Cupertino,ex1)'; [e-mail];
>>[e-mail]; [e-mail]
>>Subject: Re: [ipfix] STCP as a default transport not
>>
>>
>>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/