RE: [ipfix] STCP as a default transport not

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

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/