RE: [ipfix] STCP as a default transport not

"Carter Bullard" <carter@qosient.com> Thu, 09 October 2003 19:41 UTC

Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06818 for <ipfix-archive@lists.ietf.org>; Thu, 9 Oct 2003 15:41:39 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7gGC-0006QL-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 14:15:40 -0500
Received: from relay.pair.com ([209.68.1.20]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1A7gGA-0006QA-00 for ipfix@net.doit.wisc.edu; Thu, 09 Oct 2003 14:15:38 -0500
Received: (qmail 89492 invoked from network); 9 Oct 2003 19:15:37 -0000
Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137) by relay.pair.com with SMTP; 9 Oct 2003 19:15:37 -0000
X-pair-Authenticated: 207.237.37.137
Received: from osiris (osiris.newyork.qosient.com [192.168.0.163]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h99JFbX16249; Thu, 9 Oct 2003 15:15:37 -0400
Reply-To: carter@qosient.com
From: Carter Bullard <carter@qosient.com>
To: "'MEYER,JEFFREY D (HP-Cupertino,ex1)'" <jeff.meyer2@hp.com>, 'Benoit Claise' <bclaise@cisco.com>, stbryant@cisco.com
Cc: alex.audu@alcatel.com, 'Reinaldo Penno' <rpenno@nortelnetworks.com>, ipfix-chairs@net.doit.wisc.edu, ipfix@net.doit.wisc.edu, rrs@cisco.com
Subject: RE: [ipfix] STCP as a default transport not
Date: Thu, 09 Oct 2003 15:15:34 -0400
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A6B0@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED661CE192@ptah.newyork.qosient.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hey Jeff,
   Well RTP/UDP is the protocol for handling video, like SMPTE 292M
and compressed HDTV (RFC 3497), so it has to be ok to go to minimally,
what is it, 1.485 Gbps.

Carter


> -----Original Message-----
> From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:jeff.meyer2@hp.com]
> Sent: Thursday, October 09, 2003 2:09 PM
> To: 'carter@qosient.com'; MEYER,JEFFREY D (HP-Cupertino,ex1);
> 'Benoit Claise'; stbryant@cisco.com
> Cc: alex.audu@alcatel.com; 'Reinaldo Penno';
> ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu; rrs@cisco.com
> 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:carter@qosient.com]
> > Sent: Thursday, October 09, 2003 10:58 AM
> > To: 'MEYER,JEFFREY D (HP-Cupertino,ex1)'; 'Benoit Claise';
> > stbryant@cisco.com
> > Cc: alex.audu@alcatel.com; 'Reinaldo Penno';
> > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu;
> rrs@cisco.com
> > 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:jeff.meyer2@hp.com]
> > > Sent: Thursday, October 09, 2003 12:03 PM
> > > To: 'Benoit Claise'; stbryant@cisco.com
> > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo
> > > Penno'; MEYER,JEFFREY D (HP-Cupertino,ex1);
> > > ipfix-chairs@net.doit.wisc.edu; ipfix@net.doit.wisc.edu;
> > rrs@cisco.com
> > > 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:bclaise@cisco.com]
> > > > Sent: Thursday, October 09, 2003 9:15 AM
> > > > To: stbryant@cisco.com
> > > > Cc: alex.audu@alcatel.com; carter@qosient.com; 'Reinaldo Penno';
> > > > 'MEYER,JEFFREY D (HP-Cupertino,ex1)';
> > > ipfix-chairs@net.doit.wisc.edu;
> > > > ipfix@net.doit.wisc.edu; rrs@cisco.com
> > > > 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:majordomo@net.doit.wisc.edu and
> say "help" in
> > > > > message body
> > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > > > > "unsubscribe ipfix" in message body
> > > > > Archive     http://ipfix.doit.wisc.edu/archive/
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/