RE: [ipfix] STCP as a default transport not
"MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com> Thu, 09 October 2003 17:13 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 NAA29880 for <ipfix-archive@lists.ietf.org>; Thu, 9 Oct 2003 13:13:52 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A7eC1-0002HQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 09 Oct 2003 12:03:13 -0500
Received: from atlrel7.hp.com ([156.153.255.213]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A7eC0-0002HL-00; Thu, 09 Oct 2003 12:03:12 -0500
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id F1E6A1C02B10; Thu, 9 Oct 2003 13:03:11 -0400 (EDT)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id E6E4C1C000B5; Thu, 9 Oct 2003 13:03:11 -0400 (EDT)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <4SN0V3T2>; Thu, 9 Oct 2003 13:03:11 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960380@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.com>
To: 'Benoit Claise' <bclaise@cisco.com>, stbryant@cisco.com
Cc: alex.audu@alcatel.com, carter@qosient.com, 'Reinaldo Penno' <rpenno@nortelnetworks.com>, "MEYER,JEFFREY D (HP-Cupertino,ex1)" <jeff.meyer2@hp.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 13:03:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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/
- [ipfix] STCP as a default transport not Carter Bullard
- Re: [ipfix] STCP as a default transport not Alex Audu
- RE: [ipfix] STCP as a default transport not Carter Bullard
- Re: [ipfix] STCP as a default transport not Alex Audu
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Reinaldo Penno
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not Tal Givoly
- Re: [ipfix] STCP as a default transport not Alex Audu
- Re: [ipfix] STCP as a default transport not Stewart Bryant
- RE: [ipfix] STCP as a default transport not Reinaldo Penno
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not Carter Bullard
- Re: [ipfix] STCP as a default transport not Alex Audu
- Re: [ipfix] STCP as a default transport not Stewart Bryant
- Re: [ipfix] STCP as a default transport not Stewart Bryant
- Re: [ipfix] STCP as a default transport not Stewart Bryant
- IPFIX meeting slot has been requested for the 58t… Dave Plonka
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Reinaldo Penno
- Re: [ipfix] STCP as a default transport not Benoit Claise
- Re: [ipfix] STCP as a default transport not Benoit Claise
- Re: [ipfix] STCP as a default transport not Peter Ludemann
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Randy Bush
- RE: [ipfix] STCP as a default transport not Brown, Mark R, ALABS
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Randy Bush
- RE: [ipfix] STCP as a default transport not Peter Lei
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Randy Bush
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not Stas Khirman
- RE: [ipfix] Congestion management Nevil Brownlee
- RE: [ipfix] STCP as a default transport not Carter Bullard
- Re: [ipfix] STCP as a default transport not Benoit Claise
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] Congestion management Randy Bush
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- Re: [ipfix] STCP as a default transport not Randall Stewart (cisco)
- RE: [ipfix] STCP as a default transport not Carter Bullard
- RE: [ipfix] STCP as a default transport not Carter Bullard
- Re: [ipfix] STCP as a default transport not Peter Ludemann
- Re: [ipfix] Congestion management Stewart Bryant
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- Re: [ipfix] STCP as a default transport not Robert Lowe
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- Re: [ipfix] STCP as a default transport not Peter Lei
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- Re: [ipfix] STCP as a default transport not Alex Audu
- Re: [ipfix] STCP as a default transport not Peter Lei
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- RE: [ipfix] default transport !!! Nevil Brownlee
- Re: [ipfix] STCP as a default transport not Alex Audu
- RE: [ipfix] STCP as a default transport not MEYER,JEFFREY D (HP-Cupertino,ex1)
- Re: [ipfix] STCP as a default transport not Alex Audu
- RE: [ipfix] STCP as a default transport not Carter Bullard
- [ipfix] reporting about tossed data Maurizio Molina
- Re: [ipfix] default transport !!! Mark Fullmer
- Re: [ipfix] default transport !!! Randall Stewart (cisco)
- Re: [ipfix] default transport !!! Randy Bush
- Re: [ipfix] default transport !!! Mark Fullmer
- Re: [ipfix] default transport !!! Robert Lowe
- Re: [ipfix] default transport !!! Mark Fullmer
- Re: [ipfix] default transport !!! Randall Stewart (cisco)