RE: [ipfix] STCP as a default transport not

["Carter Bullard" <[e-mail]>]

Hey Stas,
   I'm not advocating RTP/UDP as the basis of IPFIX,
just one of the transports available.  The reasoning
is two fold.  The first, many IP flow monitors today
use simple UDP.  RTP/RTCP would be a simple addition for
these devices in order for them to get some congestion
awareness, which is all the IESG is asking for.  I can't
think of any other IETF standard protocol more perfect
for these applications, since the modification for
these devices would/could be trivial compared to
converting to a connection-oriented strategy.

   The second, when building very high speed flow monitors
to support a specific class of network monitoring
applications, the transport goals are not any different
than those of streaming video. No need to go back, we do
want to know if there is loss and if there is toooo much
loss maybe do something drastic, and we'd like the other side
to be a bit adaptive, but basically just keep it coming.
RTP/RTCP seems ideal for that.

   When RTP was in its infancy, the discussion was that
it was the go to protocol if you wanted something in-between
TCP and UDP.  Signaling and control are out-of-band so
you get all the benefits of a pure connection-less protocol,
but you can get feedback if you want it.  Did that change
somewhere along the way?

Carter



> -----Original Message-----
> From: majordomo listserver
> [mailto:[e-mail]] On Behalf Of Stas Khirman
> Sent: Thursday, October 09, 2003 4:49 PM
> To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
> '[e-mail]'; 'Benoit Claise'; [e-mail]
> Cc: [e-mail]; 'Reinaldo Penno';
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [ipfix] STCP as a default transport not
>
>
> 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/
>




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