Re: [ipfix] STCP as a default transport not

Stewart Bryant <stbryant@cisco.com> Tue, 07 October 2003 15:29 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 LAA07700 for <ipfix-archive@lists.ietf.org>; Tue, 7 Oct 2003 11:29:02 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1A6tW4-0005cD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 07 Oct 2003 10:12:48 -0500
Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1A6tW3-0005c1-00; Tue, 07 Oct 2003 10:12:47 -0500
Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2003 17:11:06 +0200
Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h97FCfk8024392; Tue, 7 Oct 2003 17:12:41 +0200 (MET DST)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-151.cisco.com [64.103.65.151]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA19740; Tue, 7 Oct 2003 16:12:44 +0100 (BST)
Message-ID: <3F82D7EB.1010101@cisco.com>
Date: Tue, 07 Oct 2003 16:12:43 +0100
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: alex.audu@alcatel.com
CC: 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
Subject: Re: [ipfix] STCP as a default transport not
References: <5C8959A16A71B449AE793CF52FBBED6607A6A9@ptah.newyork.qosient.com> <3F82D3EB.39B16507@alcatel.com>
In-Reply-To: <3F82D3EB.39B16507@alcatel.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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/