RE: [ipfix] STCP as a default transport not

[Stas Khirman <[e-mail]>]

Gentlemen,

Citing my extensive RTP/RTCP experience, I can't resist not to give my 2c to
your heated discussion. Sorry......

RTP/RTCP is designed for multimedia streaming applications, where timely
delivery of the information is significantly more important then its
completeness. Indeed, due human perception capabilities, you can lost a few
percent of voice packet without noticing any quality degradation. Video
information is even more "lost-sustainable". On the other hand, late
multimedia packet is not different from the lost one . As a result, it's
assumed than multimedia streaming application will NOT resend lost frame -
anyway, it will arrive to late (partial exception for prerecorded
video-on-demand applications with a big sender-based buffer).

Initially, RTP (data) channel is used to send a multimedia frames ( packets)
with some predefined rate. RTCP (control or feedback) channel is used to
inform sender about quality of information delivery. Certainly, it includes
lost packet ratio, but often inter-packet-delivery jitter is considered as a
more sensitive parameter. RTCP information may be used ( or have to be used,
if you expect quality) to "adapt" sender application, often by scaling
quality/bandwidth codacs parameters ( or replacing codacs on the fly).

RTP/RTCP itself has neither rate control, nor congestion avoidance and
retransmission functionalities build-in - all these features are left for an
application.

There are a few interesting RTP extension to support a [semi-]reliable
multicast, but I didn't see anything working outside university projects (
my info may be 2-3 years outdated - any corrections are welcome).

Considering said above, I do NOT recommend to use RTP/RTCP as a basis for
IPFIX - its belongs to totally different domain with [often] different
requirements and basic assumptions.

regards
Stas Khirman




> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[e-mail]]
> Sent: Thursday, October 09, 2003 12:09 PM
> To: '[e-mail]'; MEYER,JEFFREY D (HP-Cupertino,ex1); 'Benoit
> Claise'; [e-mail]
> Cc: [e-mail]; 'Reinaldo Penno';
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [ipfix] STCP as a default transport not
> 
> 
> Hi,
> 
>   I'm guessing the RTP/UDP waiver is due to some expectation that
> RTP streams in applications such as voice and video have some 
> upper bound on their consumption of resources.  E.g. a fixed 
> 500Kb/sec pump.
> 
>   In the case of Netflow, there are no guarantees of what the 
> upper bound may be.  The whole point of the discussion seems 
> centered around the inability of the exporter to handle back 
> pressure.  So things like the RTP control protocol for reporting
> observed dropped rates etc. wouldn't really help.  Or maybe
> I'm missing something.
> 
>   But hey, if all it takes is slapping 12 bytes on the front of
> the IPFIX packet to make it allowable, I'm all for it!
> 
> -- Jeff
> 
> > -----Original Message-----
> > From: Carter Bullard [mailto:[e-mail]]
> > Sent: Thursday, October 09, 2003 10:58 AM
> > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise';
> > [e-mail]
> > Cc: [e-mail]; 'Reinaldo Penno';
> > [e-mail]; [e-mail]; 
> [e-mail]
> > Subject: RE: [ipfix] STCP as a default transport not
> > 
> > 
> > I'm unhappy that the only apparent considerations are
> > connection oriented and unicast.  I'm going to use multicast
> > to move flow data in some situations, and at this point,
> > no candidate IPFIX transport is going to make it.
> > 
> > When I mentioned RTP earlier, I was not being facetious.
> > The IESG seems to think that RTP/UDP is not verboten,
> > from a congestion perspective, regardless of the speeds,
> > so I believe that that should be on a discussion list.
> > 
> > Carter
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
> [mailto:[e-mail]]
> > > Sent: Thursday, October 09, 2003 12:03 PM
> > > To: 'Benoit Claise'; [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
> > >
> > >
> > > 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/
> 

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