Network Working Group R. R. Stewart
INTERNET-DRAFT M. A. Ramalho
Cisco Systems
Q. Xie
Motorola
P. Conrad
Temple University
M. Rose
Invisible Worlds, Inc
expires in six months November 3,2000
SCTP Stream based flow control
<draft-stewart-srwnd-sctp-sigtran-01.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Taking advantage of the extensibility of SCTP, this document adds
a standard method for SCTP to provide a stream based flow control
mechanism.
Table Of Contents
1. Introduction...............................................1
2. Conventions................................................2
3. Parameter Formats..........................................2
3.1 New Parameter Types.......................................2
3.2 Stream Flow Limit Change..................................2
4. Procedures.................................................3
4.1 Stream Receiver side procedures...........................3
4.2 Stream Sender side procedures.............................4
5. Security Considerations....................................4
6. IANA considerations........................................5
7. Authors' Addresses.........................................5
7. References.................................................5
Appendix A Suggested application usage characteristics......6
1. Introduction
Taking advantage of the extensibility of SCTP, this document adds
a standard method for SCTP to provide a stream based flow control
Stewart, et al [Page 1]
Internet draft SCTP Stream based flow control November 2000
mechanism. This mechanism uses the reliable chunk transfer
extension [ADDIP] to carry the flow control restrictions to
peer endpoints that support this option. Some of the benefits
of this extension are:
A) The ability to minimize the occurrence of a single stream
hogging all transport level resources (e.g. a_rwnd).
B) The ability to dynamically change the stream buffering
limits as the situation changes within the application.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
appear in this document, are to be interpreted as described in
RFC 2119 [RFC2119].
3. Parameter Formats
Stream flow control requests MUST be delivered in a reliable
fashion. This information is used by the sending SCTP peer to limit
how much information one stream may send (based upon feedback from the
receiving peers application layer). Being that these flow changes MUST
be reliably delivered and are considered control information, the
methods specified in [ADDIP] is used to communicate this
information. Therefore this document will only specify the new
parameter required to carry the flow control requests from the
receiver side to the sender side. For the proper procedures for the
actual Reliable Chunk Transfer please see [ADDIP].
3.1 New Parameter Types
Variable Parameters Type Value
-------------------------------------------------
Stream Flow limit Request 32771 (0xC003)
3.2 Stream Flow Limit Change
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32771 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 | Flow Limit 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N | Flow Limit N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stewart, et al [Page 2]
Internet draft SCTP Stream based flow control November 2000
Stream Number n : 16 bits (unsigned integer)
This is the stream number that is requesting a limit be placed
on the sender based on the applications receive buffer sizes.
Flow Limit n : 16 bits (unsigned integer)
This is the limit the receiver is requesting (in bytes) as to
the maximum amount of data that the receiver may accept. Note
that the value 0 holds a special meaning described in Section 4.1.
4. Procedures
A stream in SCTP is an uni-directional logical channel established from
one to another associated SCTP endpoint, within which all user
messages are delivered in sequence except for those submitted to the
unordered delivery service which may arrive out of sequence. Since
each stream is uni-directional and no feedback mechanism exists to
limit a sender, it is possible for one unique stream to hog all of the
transport level receiver window space. The mechanism defined here
attempts to alleviate this problem by allowing the receiver side to
communicate to the sender a limit on how much outstanding data may be
sent within a particular stream.
The procedures defined here are broken down into two sides:
o The stream receiver or peer requesting the limit. And,
o the stream sender side or peer that MUST honor the
limit request.
The receivers side is mainly involved with sending the request
to the peer. The senders side is where the actual limitations
and flow control will occur.
4.1 Stream Receiver side procedures
The receiver side SCTP makes decisions on stream flow
control based on upper layer input. Normally the upper layer makes a
request to limit all or a subset of the active streams that send data
to it via an API interface. How this decision is made is outside the
scope of this document but suggested usage characteristics can be
found in Appendix A [Editors note: appendix A will be completed
in a future draft].
Any time flow limits are made known to the SCTP endpoint by the
application, the receiver side will create a Reliable Control Chunk
(based on the rules found in [ADDIP]) and attach to it one or more
stream flow limits with there respective stream number. If the
receiver wishes to remove all limits (previously placed on a
particular stream) it may do so by placing the special value '0' in
the 'Flow Limit' field. Once acknowledged by the peer endpoint the
receiver should consider the limit in place.
Stewart, et al [Page 3]
Internet draft SCTP Stream based flow control November 2000
Note that the parameter type field upper two bits dictates that any
parameter not understood should be skipped and reported to the sender
with an Operational Error. If an Operational Error is received that
indicates that the 'Stream Flow Limit Request' is not understood, the
sender of the limit request MUST not send subsequent limit
requests. The endpoint SHOULD also inform the upper level application
that the peer endpoint does not support this feature.
If the sender of the request receives a Operational Error indicating
that the REL-REQ chunk type (described in [ADDIP]) is not understood
then the sender must not send subsequent limit requests. The
endpoint SHOULD also inform the upper level application
that the peer endpoint does not support this feature.
4.2 Stream Sender side procedures
When a 'Stream Flow Limit Request' is received the sender MUST
record each flow limit with its appropriate stream.
After a limit is set on a stream the sender MUST obey the following rules
when sending to the peer on that stream:
R1) When the upper layer application attempts to send to the
peer on a stream, check the number of outstanding bytes
sent to that stream (those TSN's in queue to be sent, which
the cumulative TSN Acknowledgement has not passed, on this
stream) versus the limit set for that stream (The last received
limit for this stream is henceforth termed the current limit).
R2) If the number of outstanding bytes is greater than or
equal to the current limit, the SCTP endpoint MUST reject the
request and NOT queue the data for transmit. Instead it
SHOULD return an error to the sending application.
R3) If the number of outstanding bytes is less than the
current limit, validate that the data to be sent plus the
number of outstanding bytes is smaller than or equal to
this limit. If the user data plus the number of outstanding
bytes is smaller than or equal to the current limit accept
the data for transmit and queue the user data (increasing
the number of outstanding data bytes on this stream). If
the user data plus the number of outstanding bytes is larger
than the current limit for this stream, the SCTP endpoint MUST reject
the request and NOT queue the data for transmit and instead
SHOULD return an error to the application.
R4) Any time a stream limit is updated to the value of 0, consider
this indication to mean no limit is in effect for this stream.
Note that the effect of rule R3 above places a maximum size upon
a sender. Even though SCTP may be capable of sending and reassembling
larger user messages, by placing a flow limit on a stream this also
gates the largest single user message a receiver is willing to
accept.
5. Security Considerations
This extension is not deemed to create any additional security
hazards then currently exist in an SCTP association. All of the
threats and measures as defined in [RFC2960] are applicable to
this feature.
Stewart, et al [Page 4]
Internet draft SCTP Stream based flow control November 2000
6. IANA considerations
No new IANA considerations are added by this document. One new parameter
type is being allocated for use by this feature.
7. Authors' Addresses
Randall R. Stewart Tel: +1-815-342-5222
Cisco Systems, Inc. EMail: rrs@cisco.com
8745 W. Higgins Road, Suite 200
Chicago, Ill 60631
USA
Micheal A. Ramalho Tel: +1-732-809-0188
Cisco Systems, Inc. EMail: mramalho@cisco.com
1802 Rue de la Porte
Wall Township, NJ 0719-3784
Qiaobing Xie Tel: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA
Phil Conrad Tel: +1-XXX-XXX-XXXX
Netlab Research Group Email conrad@joda.cis.temple.edu
Dept. Of Computer &
Information Sciences
Temple University
1805 N Broad St.
Philadelphia, PA 19122
USA
Marshall T. Rose Tel: +1 707 789 3700
Invisible Worlds, Inc. EMail: mrose@invisible.net
1179 North McDowell Boulevard URI: http://invisible.net/
Petaluma, CA 94954-6559
USA
7. References
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson,
"Stream Control Transmission Protocol," RFC XXXX, October 2000.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
Stewart, et al [Page 5]
Internet draft SCTP Stream based flow control November 2000
[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.",
RFC 2402, November 1998.
[ADDIP] R. R. Stewart,Q. Xie, M. Tuexen, "SCTP Dynamic Addition
of IP addresses", Work in Progress, ietf draft.
Appendix A Suggested application usage characteristics
[ This section will be filled in in a future version of the draft ]
This Internet Draft expires in 6 months from November, 2000
Stewart, et al [Page 6]