RE: [ipfix] STCP as a default transport not

["MEYER,JEFFREY D (HP-Cupertino,ex1)" <[e-mail]>]

Benoit,

  I am not in any way against specifying IPFIX on top of PR-SCTP,
what I am against is making that the ONLY supported transport.
This is for practical reasons, like availability of implementation.
And as cited before because of transport protocols' affinity
for running in kernel vs. user space, the availability is going
to be a lot slower coming than one might like.

  I would liken this to deciding to define a transport layer
protocol which could only run on IPv6 and not IPv4.  You could,
but if you can run on both, I think there are decided benefits.

  The Diameter authors seemed to have made this pragmatic choice.

  It is a bit ironic that previous decisions of the WG around
choice of candidate protocols were ultimately trumped by "practical
reasons" like NF is more widely deployed, despite the fact
that it was the only protocol with NO binding to a congestion
aware transport.  And now, the arguments seem to be a complete
180 change.

Regards,

  Jeff Meyer

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