Additional Policies for the Partially Reliable
Stream Control Transmission Protocol Extension
Muenster University of Applied SciencesStegerwaldstrasse 3948565 SteinfurtGermanytuexen@fh-muenster.deMetafinanz Informationssysteme GmbHLeopoldstrasse 14680804 MuenchenGermanyrfc@robin-seggelmann.comNetflix, Inc.ChapinSC29036United Statesrandall@lakerest.netEricssonHirsalantie 11Jorvas 02420 FinlandSalvatore.Loreto@ericsson.comThis document defines two additional policies for the Partially Reliable
Stream Control Transmission Protocol (PR-SCTP) extension. These policies allow limitation of the number of retransmissions and prioritization of user messages for
more efficient usage of the send buffer.The Partially Reliable SCTP (PR-SCTP) extension defined in
provides a generic method for senders to
abandon user messages. The decision to abandon a user message
is sender side only, and the exact condition is called a "PR-SCTP policy"
( refers to them as "PR-SCTP Services").
also defines one particular PR-SCTP policy,
called "Timed Reliability". This allows the sender to specify a timeout
for a user message after which the SCTP stack abandons the user message.This document specifies the following two additional PR-SCTP policies:
Allows limitation of the number of retransmissions.
Allows removal of lower-priority messages if space for higher-priority messages is needed in the send buffer.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
.This section defines two new PR-SCTP policies, one in each subsection.Please note that it is REQUIRED to implement ,
if you want to implement these additional policies. However, these
additional policies are OPTIONAL when implementing .Using the Limited Retransmission Policy allows the sender of a user message
to specify an upper limit for the number of retransmissions for each DATA chunk
of the given user messages. The sender MUST abandon a user message if the
number of retransmissions of any of the DATA chunks of the user message
would exceed the provided limit. The sender MUST perform all other actions
required for processing the retransmission event, such as adapting
the congestion window and the retransmission timeout.
Please note that the number of retransmissions includes both fast and
timer-based retransmissions.The sender MAY limit the number of retransmissions to 0. This will
result in abandoning the message when it would get retransmitted for
the first time. The use of this setting provides a service similar to UDP,
which also does not perform any retransmissions.Please note that using this policy does not affect the handling of the
thresholds 'Association.Max.Retrans' and 'Path.Max.Retrans' as specified
in Section 8 of .The WebRTC protocol stack (see )
is an example of where the Limited Retransmissions Policy is used.Using the Priority Policy allows the sender of a user message to specify
a priority. When storing a user message in the send buffer while there is not
enough available space, the SCTP stack at the sender side MAY abandon other
user message(s) of the same SCTP association (with the same or a different
stream) with a priority lower than the provided one.
User messages sent reliably are considered to have a priority higher than
all messages sent with the Priority Policy.
The algorithm for selecting the message(s) being abandoned is implementation
specific.After lower-priority messages have been abandoned, high-priority
messages can be transferred without the send call blocking (if used
in blocking mode) or the send call failing (if used in non-blocking
mode).The IP Flow Information Export (IPFIX) protocol stack (see ) is an example
of where the Priority Policy can be used.
Template records would be sent with
full reliability, while flow records related to billing, security,
and other monitoring would be sent using the Priority Policy with
varying priority. The priority of security-related flow records would
be set higher than the priority of monitoring-related flow records.
This section describes how the socket API defined in
is extended to support the newly defined
PR-SCTP policies, to provide some statistical information, and to
control the negotiation of the PR-SCTP extension during the
SCTP association setup.Please note that this section is informational only.This section uses data types from :
uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t).
This is the same as in .As defined in , the PR-SCTP policy is
specified and configured by using the following sctp_prinfo structure:
struct sctp_prinfo {
uint16_t pr_policy;
uint32_t pr_value;
};
When the Limited Retransmission Policy described in
is used, pr_policy has the value SCTP_PR_SCTP_RTX and the number of
retransmissions is given in pr_value.When using the Priority Policy described in ,
pr_policy has the value SCTP_PR_SCTP_PRIO. The priority is given
in pr_value. The value of zero is the highest priority, and larger numbers in
pr_value denote lower priorities.The following table summarizes the possible parameter settings defined in
and this document:pr_policypr_valueSpecificationSCTP_PR_SCTP_NONEIgnoredSCTP_PR_SCTP_TTLLifetime in msSCTP_PR_SCTP_RTXNumber of retransmissionsSCTP_PR_SCTP_PRIOPriorityThis socket option uses IPPROTO_SCTP as its level and SCTP_PR_STREAM_STATUS
as its name. It can only be used with getsockopt() but not with setsockopt().
The socket option value uses the following structure:
struct sctp_prstatus {
sctp_assoc_t sprstat_assoc_id;
uint16_t sprstat_sid;
uint16_t sprstat_policy;
uint64_t sprstat_abandoned_unsent;
uint64_t sprstat_abandoned_sent;
};
This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates for which association
the user wants the information. It is an error to use
SCTP_{CURRENT|ALL|FUTURE}_ASSOC in sprstat_assoc_id.
This parameter indicates for which outgoing SCTP stream the user wants the
information.
This parameter indicates for which PR-SCTP policy the user wants the information.
It is an error to use SCTP_PR_SCTP_NONE in sprstat_policy.
If SCTP_PR_SCTP_ALL is used, the counters provided are aggregated over all
supported policies.
The number of user messages that have been abandoned using the policy
specified in sprstat_policy on the stream specified in sprstat_sid for the
association specified by sprstat_assoc_id,
before any part of the user message could be sent.
The number of user messages that have been abandoned using the policy
specified in sprstat_policy on the stream specified in sprstat_sid for the
association specified by sprstat_assoc_id,
after a part of the user message has been sent.
There are separate counters for unsent and sent user messages because
the SCTP_SEND_FAILED_EVENT supports a similar differentiation.
Please note that an abandoned large user message requiring SCTP-level
fragmentation is reported in the sprstat_abandoned_sent counter as soon as
at least one fragment of it has been sent. Therefore, each abandoned user
message is counted in either sprstat_abandoned_unsent or
sprstat_abandoned_sent.If more detailed information about abandoned user messages is required,
the subscription to the SCTP_SEND_FAILED_EVENT is recommended.
Please note that some implementations might choose not to support this option,
since it increases the resources needed for an outgoing SCTP stream.
For the same reasons, some implementations might only support using
SCTP_PR_SCTP_ALL in sprstat_policy.sctp_opt_info() needs to be extended to support SCTP_PR_STREAM_STATUS.This socket option uses IPPROTO_SCTP as its level and SCTP_PR_ASSOC_STATUS
as its name. It can only be used with getsockopt(), but not with setsockopt().
The socket option value uses the same structure as described in
:
struct sctp_prstatus {
sctp_assoc_t sprstat_assoc_id;
uint16_t sprstat_sid;
uint16_t sprstat_policy;
uint64_t sprstat_abandoned_unsent;
uint64_t sprstat_abandoned_sent;
};
This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates for which association
the user wants the information. It is an error to use
SCTP_{CURRENT|ALL|FUTURE}_ASSOC in sprstat_assoc_id.
This parameter is ignored.
This parameter indicates for which PR-SCTP policy the user wants the information.
It is an error to use SCTP_PR_SCTP_NONE in sprstat_policy.
If SCTP_PR_SCTP_ALL is used, the counters provided are aggregated over all
supported policies.
The number of user messages that have been abandoned using the policy
specified in sprstat_policy for the association specified by sprstat_assoc_id,
before any part of the user message could be sent.
The number of user messages that have been abandoned using the policy
specified in sprstat_policy for the association specified by sprstat_assoc_id,
after a part of the user message has been sent.
There are separate counters for unsent and sent user messages because
the SCTP_SEND_FAILED_EVENT supports a similar differentiation.
Please note that an abandoned large user message requiring SCTP-level
fragmentation is reported in the sprstat_abandoned_sent counter as soon as
at least one fragment of it has been sent. Therefore, each abandoned user
message is counted in either sprstat_abandoned_unsent or
sprstat_abandoned_sent.If more detailed information about abandoned user messages is required,
the usage of the option described in or
the subscription to the SCTP_SEND_FAILED_EVENT is recommended.sctp_opt_info() needs to be extended to support SCTP_PR_ASSOC_STATUS.This socket option allows the enabling or disabling of the negotiation
of PR-SCTP support for future associations.
For existing associations, it allows one to query whether or not PR-SCTP support was
negotiated on a particular association.Whether or not PR-SCTP is enabled by default is implementation specific.This socket option uses IPPROTO_SCTP as its level and SCTP_PR_SUPPORTED
as its name. It can be used with getsockopt() and setsockopt().
The socket option value uses the following structure
defined in :
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates upon which association
the user is performing an action.
The special sctp_assoc_t SCTP_FUTURE_ASSOC can also be used;
it is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
A non-zero value encodes the enabling of PR-SCTP, whereas a value of 0 encodes
the disabling of PR-SCTP.sctp_opt_info() needs to be extended to support SCTP_PR_SUPPORTED.This document does not add any security considerations
to those given in
,
, and
.
As indicated in the Security Considerations of ,
transport-layer security in the form of TLS over SCTP
(see ) can't be used for PR-SCTP.
However, DTLS over SCTP (see ) could be used instead.
If DTLS over SCTP as specified in is used, the
Security Considerations of do apply.
It should also be noted that using PR-SCTP for an SCTP association doesn't
allow that association to behave more aggressively
than an SCTP association not using PR-SCTP.WebRTC Data ChannelsThe WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer.Protocol Independent InterfacesIEEEThe authors wish to thank
Benoit Claise,
Spencer Dawkins,
Gorry Fairhurst,
Stephen Farrell,
Barry Leiba,
Karen Egede Nielsen,
Ka&nbhy;Cheong Poon,
Dan Romascanu,
Irene Ruengeler,
Jamal Hadi Salim,
Joseph Salowey,
Brian Trammell,
and Vlad Yasevich
for their invaluable comments.