< draft-ietf-tsvwg-sctp-ndata-07.txt		draft-ietf-tsvwg-sctp-ndata-08.txt >
	Network Working Group R. Stewart		Network Working Group R. Stewart
	Internet-Draft Netflix, Inc.		Internet-Draft Netflix, Inc.
	Intended status: Standards Track M. Tuexen		Intended status: Standards Track M. Tuexen
	Expires: January 22, 2017 Muenster Univ. of Appl. Sciences		Expires: May 4, 2017 Muenster Univ. of Appl. Sciences
	S. Loreto		S. Loreto
	Ericsson		Ericsson
	R. Seggelmann		R. Seggelmann
	Metafinanz Informationssysteme GmbH		Metafinanz Informationssysteme GmbH
	July 21, 2016		October 31, 2016
	Stream Schedulers and User Message Interleaving for the Stream Control		Stream Schedulers and User Message Interleaving for the Stream Control
	Transmission Protocol		Transmission Protocol
	draft-ietf-tsvwg-sctp-ndata-07.txt		draft-ietf-tsvwg-sctp-ndata-08.txt
	Abstract		Abstract
	The Stream Control Transmission Protocol (SCTP) is a message oriented		The Stream Control Transmission Protocol (SCTP) is a message oriented
	transport protocol supporting arbitrary large user messages.		transport protocol supporting arbitrary large user messages. This
	However, the sender can not interleave different user messages which		document adds a new data chunk to SCTP. This allows a sender to
	causes head of line blocking at the sender side. To overcome this		interleave different user messages that would otherwise result in
	limitation, this document adds a new data chunk to SCTP.		head of line blocking at the sender.
	Whenever an SCTP sender is allowed to send a user data, it can		Whenever an SCTP sender is allowed to send user data, it may choose
	possibly choose from multiple outgoing SCTP streams. Multiple ways		from multiple outgoing SCTP streams. Multiple ways for performing
	for this selection, called stream schedulers, are defined. Some of		this selection, called stream schedulers, are defined. A stream
	them don't require the support of user message interleaving, some do.		scheduler can choose to either implement, or not implement, user
			message interleaving.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 22, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
	2. User Message Interleaving . . . . . . . . . . . . . . . . . . 5		2. User Message Interleaving . . . . . . . . . . . . . . . . . . 5
	2.1. The I-DATA Chunk supporting User Message Interleaving . . 5		2.1. The I-DATA Chunk supporting User Message Interleaving . . 6
	2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 7		2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 7
	2.2.2. Sender Side Considerations . . . . . . . . . . . . . 8		2.2.2. Sender Side Considerations . . . . . . . . . . . . . 8
	2.2.3. Receiver Side Considerations . . . . . . . . . . . . 8		2.2.3. Receiver Side Considerations . . . . . . . . . . . . 8
	2.3. Interaction with other SCTP Extensions . . . . . . . . . 8		2.3. Interaction with other SCTP Extensions . . . . . . . . . 9
	2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 9		2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 9
	2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 10		2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 10
	3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 10		3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 10
	3.1. First Come First Serve (SCTP_SS_FCFS) . . . . . . . . . . 10		3.1. First Come First Serve (SCTP_SS_FCFS) . . . . . . . . . . 10
	3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 11		3.2. Round Robin Scheduler (SCTP_SS_RR) . . . . . . . . . . . 11
	3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 11		3.3. Round Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . . 11
	3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 11		3.4. Priority Based Scheduler (SCTP_SS_PRIO) . . . . . . . . . 11
	3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . . . 11		3.5. Fair Bandwidth Scheduler (SCTP_SS_FB) . . . . . . . . . . 11
	3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 11		3.6. Weighted Fair Queueing Scheduler (SCTP_SS_WFQ) . . . . . 11
	4. Socket API Considerations . . . . . . . . . . . . . . . . . . 12		4. Socket API Considerations . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	When SCTP [RFC4960] was initially designed it was mainly envisioned		When SCTP [RFC4960] was initially designed it was mainly envisioned
	for the transport of small signaling messages. Late in the design		for the transport of small signaling messages. Late in the design
	stage it was decided to add support for fragmentation and reassembly		stage it was decided to add support for fragmentation and reassembly
	of larger messages with the thought that someday Session Initiation		of larger messages with the thought that someday Session Initiation
	Protocol (SIP) [RFC3261] style signaling messages may also need to		Protocol (SIP) [RFC3261] style signaling messages may also need to
	use SCTP and a single MTU sized message would be too small.		use SCTP and a single Maximum Transmission Unit (MTU) sized message
	Unfortunately this design decision, though valid at the time, did not		would be too small. Unfortunately this design decision, though valid
	account for other applications which might send very large messages		at the time, did not account for other applications that might send
	over SCTP. When such large messages are now sent over SCTP a form of		large messages over SCTP. When such large messages are sent over
	sender side head of line blocking becomes created within the		SCTP as specified in [RFC4960] can result in a form of sender side
	protocol. This head of line blocking is caused by the use of the		head of line blocking (e.g., when the transmission of an urgent
	Transmission Sequence Number (TSN) for three different purposes:		message is blocked from transmission because the sender has started
			transmission of another, possibly large, message). This head of line
			blocking is caused by the use of the Transmission Sequence Number
			(TSN) for three different purposes:
	1. As an identifier for DATA chunks to provide a reliable transfer.		1. As an identifier for DATA chunks to provide a reliable transfer.
	2. As an identifier for the sequence of fragments to allow		2. As an identifier for the sequence of fragments to allow
	reassembly.		reassembly.
	3. As a sequence number allowing to have up to 2**16 - 1 Stream		3. As a sequence number allowing to have up to 2**16 - 1 Stream
	Sequence Numbers (SSNs) outstanding.		Sequence Numbers (SSNs) outstanding.
	The protocol requires all fragments of a user message to have		The protocol requires all fragments of a user message to have
	consecutive TSNs. Therefore it is impossible for the sender to		consecutive TSNs. Therefore it is impossible for the sender to
	interleave different user messages.		interleave different user messages.
	This document also defines several stream schedulers for general SCTP		This document also defines several stream schedulers for general SCTP
	associations. If support for user message interleaving has been		associations. If support for user message interleaving has been
	negotiated, several more schedulers are available.		negotiated, several more schedulers are available.
	The following Figure 1 illustrates the behaviour of a round robin		The following Figure 1 illustrates the behaviour of a round robin
	stream scheduler using DATA chunks. Please note that the use of such		stream scheduler using DATA chunks. Please note that the use of such
	an scheduler implies late TSN assignment but it can be used with an		a scheduler implies late TSN assignment but it can be used with an
	[RFC4960] compliant implementation not supporting user message		[RFC4960] compliant implementation not supporting user message
	interleaving.		interleaving.
	+---+---+---+		+---+---+---+
	| 0/0 |-+		| 0/0 |-+
	+---+---+---+ |		+---+---+---+ |
	| +---+---+---+---+---+---+---+---+---+		| +---+---+---+---+---+---+---+---+---+
	+---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0|		+---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0|
	|1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---|		|1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---|
	+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |		+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	Figure 1: Round Robin Scheduler without User Message Interleaving		Figure 1: Round Robin Scheduler without User Message Interleaving
	This document describes a new Data chunk called I-DATA. This chunk		This document describes a new Data chunk called I-DATA. This chunk
	incorporates all the flags and fields except the Stream Sequence		incorporates all the flags and fields except the Stream Sequence
	Number (SSN) and properties of the current SCTP Data chunk but also		Number (SSN) and properties of the current SCTP Data chunk but also
	adds two new fields in its chunk header, the Fragment Sequence Number		adds two new fields in its chunk header, the Fragment Sequence Number
	(FSN) and the Message Identifier (MID). Then the FSN is only used		(FSN) and the Message Identifier (MID). Then the FSN is only used
	for reassembling all fragments having the same MID and ordering		for reassembling all fragments having the same MID and ordering
	property. The TSN is used only for the reliable transfer in		property. The TSN is used only for the reliable transfer in
	combination with SACK chunks.		combination with Selective Acknowledgment (SACK) chunks.
	The MID is also used for ensuring ordered delivery, therefore		In addition, the MID is also used for ensuring ordered delivery
	replacing the stream sequence number. Therefore, the head of line		instead of using the stream sequence number, which has been omitted
	blocking caused by the original design is avoided.		from the I-DATA chunk.
	The following Figure 2 illustrates the behaviour of an interleaving		The following Figure 2 illustrates the behaviour of an interleaving
	round robin stream scheduler using I-DATA chunks.		round robin stream scheduler using I-DATA chunks.
	+---+---+---+		+---+---+---+
	| 0/0 |-+		| 0/0 |-+
	+---+---+---+ |		+---+---+---+ |
	| +-----+-----+-----+-----+-----+-----+-----+-----+-----+		| +-----+-----+-----+-----+-----+-----+-----+-----+-----+
	+---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0|		+---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0|
	|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----|		|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----|
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	+-------+ |SID/MID/FSN|		+-------+ |SID/MID/FSN|
	|SID/MID| |-----------|		|SID/MID| |-----------|
	+-------+ | TSN |		+-------+ | TSN |
	+-----------+		+-----------+
	Figure 2: Round Robin Scheduler with User Message Interleaving		Figure 2: Round Robin Scheduler with User Message Interleaving
	The support of the I-DATA chunk is negotiated during the association		The support of the I-DATA chunk is negotiated during the association
	setup using the Supported Extensions Parameter as defined in		setup using the Supported Extensions Parameter as defined in
	[RFC5061]. If I-DATA support has been negotiated for an association		[RFC5061]. If I-DATA support has been negotiated for an association
	I-DATA chunks are used for all user-messages and no DATA chunks. It		I-DATA chunks are used for all user-messages. DATA chunks are not
	should be noted, that an SCTP implementation needs to support the		permitted when I-DATA support has been negotiated. It should be
	coexistence of associations using DATA chunks and associations using		noted, that an SCTP implementation needs to support the coexistence
	I-DATA chunks.		of associations using DATA chunks and associations using I-DATA
			chunks.
			This document specifies in Section 2 the user message interleaving by
			defining the I-DATA chunk, the procedures to use it and its
			interactions with other SCTP extensions. Multiple stream schedulers
			are defined in Section 3 followed by describing in Section 4 an
			extension to the socket API for using what is specified in this
			document.
	1.2. Conventions		1.2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. User Message Interleaving		2. User Message Interleaving
	The interleaving of user messages is required for WebRTC Datachannels		The interleaving of user messages is required for WebRTC Datachannels
	as specified in [I-D.ietf-rtcweb-data-channel].		as specified in [I-D.ietf-rtcweb-data-channel].
			An SCTP implementation supporting user message interleaving is
			REQUIRED to support the coexistence of associations using DATA chunks
			and associations using I-DATA chunks. If an SCTP implementation
			supports user message interleaving and the extension described in
			[RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding
			changes specified in Section 2.3.
	2.1. The I-DATA Chunk supporting User Message Interleaving		2.1. The I-DATA Chunk supporting User Message Interleaving
	The following Figure 3 shows the new I-DATA chunk allowing user		The following Figure 3 shows the new I-DATA chunk allowing user
	messages interleaving.		messages interleaving.
	0 1 2 3		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		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 = 64 | Res |I|U|B|E| Length |		| Type = 64 | Res |I|U|B|E| Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 42 ¶
	note that the FSN is in "network byte order", a.k.a. Big Endian.		note that the FSN is in "network byte order", a.k.a. Big Endian.
	2.2. Procedures		2.2. Procedures
	This subsection describes how the support of the I-DATA chunk is		This subsection describes how the support of the I-DATA chunk is
	negotiated and how the I-DATA chunk is used by the sender and		negotiated and how the I-DATA chunk is used by the sender and
	receiver.		receiver.
	2.2.1. Negotiation		2.2.1. Negotiation
	A sender MUST NOT send a I-DATA chunk unless both peers have		A sender MUST NOT send an I-DATA chunk unless both peers have
	indicated its support of the I-DATA chunk type within the Supported		indicated its support of the I-DATA chunk type within the Supported
	Extensions Parameter as defined in [RFC5061]. If I-DATA support has		Extensions Parameter as defined in [RFC5061]. If I-DATA support has
	been negotiated on an association, I-DATA chunks MUST be used for all		been negotiated on an association, I-DATA chunks MUST be used for all
	user messages and DATA-chunk MUST NOT be used. If I-DATA support has		user messages and DATA-chunk MUST NOT be used. If I-DATA support has
	not been negotiated on an association, DATA chunks MUST be used for		not been negotiated on an association, DATA chunks MUST be used for
	all user messages and I-DATA chunks MUST NOT be used.		all user messages and I-DATA chunks MUST NOT be used.
	A sender MUST NOT use the I-DATA chunk unless the user has requested		A sender MUST NOT use the I-DATA chunk unless the user has requested
	that use (e.g. via the socket API, see Section 4). This constraint		that use (e.g. via the socket API, see Section 4.3). This constraint
	is made since usage of this chunk requires that the application be		is made since usage of this chunk requires that the application be
	willing to interleave messages upon reception within an association.		willing to interleave messages upon reception within an association.
	This is not the default choice within the socket API (see [RFC6458])		This is not the default choice within the socket API (see [RFC6458])
	thus the user MUST indicate support to the protocol of the reception		thus the user MUST indicate support to the protocol of the reception
	of completely interleaved messages. Note that for stacks that do not		of completely interleaved messages. Note that for stacks that do not
	implement [RFC6458] they may use other methods to indicate		implement [RFC6458] they may use other methods to indicate
	interleaved message support and thus enable the usage of the I-DATA		interleaved message support and thus enable the usage of the I-DATA
	chunk, the key is that the stack MUST know the application has		chunk, the key is that the stack MUST know the application has
	indicated its choice in wanting to use the extension.		indicated its choice in wanting to use the extension.
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 34 ¶
	Note that the usage of this chunk implies the late assignment of the		Note that the usage of this chunk implies the late assignment of the
	actual TSN to any chunk being sent. Each I-DATA chunk uses a single		actual TSN to any chunk being sent. Each I-DATA chunk uses a single
	TSN. This way messages from other streams may be interleaved with		TSN. This way messages from other streams may be interleaved with
	the fragmented message. Please note that this is the only form of		the fragmented message. Please note that this is the only form of
	interleaving support. For example, it is not possible to interleave		interleaving support. For example, it is not possible to interleave
	multiple ordered or unordered user messages from the same stream.		multiple ordered or unordered user messages from the same stream.
	The sender MUST NOT be fragmenting more than one user message in any		The sender MUST NOT be fragmenting more than one user message in any
	given stream at any time. At any time, a sender MAY fragment		given stream at any time. At any time, a sender MAY fragment
	multiple user message, each of them on different streams.		multiple user messages, each of them on different streams.
	The sender MUST assign TSN's in a way that the receiver can make		The sender MUST assign TSN's in a way that the receiver can make
	progress. One way to achieve this is to assign the later fragments		progress. One way to achieve this is to assign the later fragments
	of a user message a higher TSN and send out the TSNs in sequence.		of a user message a higher TSN and send out the TSNs in sequence.
	2.2.3. Receiver Side Considerations		2.2.3. Receiver Side Considerations
	Upon reception of an SCTP packet containing a I-DATA chunk if the		Upon reception of an SCTP packet containing an I-DATA chunk if the
	message needs to be reassembled, then the receiver MUST use the FSN		message needs to be reassembled, then the receiver MUST use the FSN
	for reassembly of the message and not the TSN. The receiver MUST NOT		for reassembly of the message and not the TSN. The receiver MUST NOT
	make any assumption about the TSN assignments of the sender. Note		make any assumption about the TSN assignments of the sender. Note
	that a non-fragmented message is indicated by the fact that both the		that a non-fragmented message is indicated by the fact that both the
	'E' and 'B' bits are set. An ordered or unordered fragmented message		'E' and 'B' bits are set. A message (either ordered or unordered)
	is thus identified by not having both bits set.		may be identified as being fragmented by seeing that not both bits
			have been set.
	2.3. Interaction with other SCTP Extensions		2.3. Interaction with other SCTP Extensions
	The usage of the I-DATA chunk might interfere with other SCTP		The usage of the I-DATA chunk might interfere with other SCTP
	extensions. Future SCTP extensions MUST describe if and how they		extensions. Future SCTP extensions MUST describe if and how they
	interfere with the usage of I-DATA chunks. For the SCTP extensions		interfere with the usage of I-DATA chunks. For the SCTP extensions
	already defined when this document was published, the details are		already defined when this document was published, the details are
	given in the following subsections.		given in the following subsections.
	2.3.1. SCTP Partial Reliability Extension		2.3.1. SCTP Partial Reliability Extension
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 34 ¶
	Support for the I-FORWARD-TSN chunk is negotiated during the SCTP		Support for the I-FORWARD-TSN chunk is negotiated during the SCTP
	association setup via the Supported Extensions Parameter as defined		association setup via the Supported Extensions Parameter as defined
	in [RFC5061]. Only if both end points support the I-DATA chunk and		in [RFC5061]. Only if both end points support the I-DATA chunk and
	the I-FORWARD-TSN chunk, the partial reliability extension can be		the I-FORWARD-TSN chunk, the partial reliability extension can be
	used in combination with user message interleaving.		used in combination with user message interleaving.
	2.3.2. SCTP Stream Reconfiguration Extension		2.3.2. SCTP Stream Reconfiguration Extension
	When an association resets the SSN using the SCTP extension defined		When an association resets the SSN using the SCTP extension defined
	in [RFC6525], the two counters (one for the ordered messages, one for		in [RFC6525], the two counters (one for the ordered messages, one for
	the unordered messages) used for the MID MUST be reset to 0		the unordered messages) used for the MID MUST be reset to 0.
	correspondingly.
	Since most schedulers, especially all schedulers when supporting user		Since most schedulers, especially all schedulers supporting user
	message interleaving, require late TSN assignment, it should be noted		message interleaving, require late TSN assignment, it should be noted
	that the implementation of [RFC6525] needs to handle this.		that the implementation of [RFC6525] needs to handle this.
	3. Stream Schedulers		3. Stream Schedulers
	This section defines several stream schedulers. The streams		This section defines several stream schedulers. The stream
	schedulers may behave differently depending on whether user message		schedulers may behave differently depending on whether user message
	interleaving has been negotiated for the association or not. The set		interleaving has been negotiated for the association or not. The set
	of schedulers being implemented is implementation dependent.		of schedulers being implemented is implementation dependent.
	3.1. First Come First Serve (SCTP_SS_FCFS)		3.1. First Come First Serve (SCTP_SS_FCFS)
	The simple first-come, first-serve scheduler of user messages is		The simple first-come, first-serve scheduler of user messages is
	used. It just passes through the messages in the order in which they		used. It just passes through the messages in the order in which they
	have been delivered by the application. No modification of the order		have been delivered by the application. No modification of the order
	is done at all. The usage of user message interleaving does not		is done at all. The usage of user message interleaving does not
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 24 ¶
	Please note that this section is informational only.		Please note that this section is informational only.
	4.1. Exposition of the Stream Sequence Number (SSN)		4.1. Exposition of the Stream Sequence Number (SSN)
	The socket API defined in [RFC6458] defines several structures in		The socket API defined in [RFC6458] defines several structures in
	which the SSN of a received user message is exposed to the		which the SSN of a received user message is exposed to the
	application. The list of these structures includes:		application. The list of these structures includes:
	struct sctp_sndrcvinfo		struct sctp_sndrcvinfo
	Specified in Section 5.3.2 of [RFC6458] and being deprecated.		Specified in Section 5.3.2 of [RFC6458] and marked as deprecated.
	struct sctp_extrcvinfo		struct sctp_extrcvinfo
	Specified in Section 5.3.3 of [RFC6458] and being deprecated.		Specified in Section 5.3.3 of [RFC6458] and marked as deprecated.
	struct sctp_rcvinfo		struct sctp_rcvinfo
	Specified in Section 5.3.5 of [RFC6458].		Specified in Section 5.3.5 of [RFC6458].
	If user message interleaving is used, the lower order 16 bits of the		If user message interleaving is used, the lower order 16 bits of the
	MID are used as the SSN when filling out these structures.		MID are used as the SSN when filling out these structures.
	4.2. SCTP_ASSOC_CHANGE Notification		4.2. SCTP_ASSOC_CHANGE Notification
	When an SCTP_ASSOC_CHANGE notification is delivered indicating a		When an SCTP_ASSOC_CHANGE notification is delivered indicating a
	skipping to change at page 15, line 47 ¶		skipping to change at page 15, line 47 ¶
	stream_id: Holds the stream id for the stream for which additional		stream_id: Holds the stream id for the stream for which additional
	information has to be provided.		information has to be provided.
	stream_value: The meaning of this field depends on the scheduler		stream_value: The meaning of this field depends on the scheduler
	specified. It is ignored when the scheduler does not need		specified. It is ignored when the scheduler does not need
	additional information.		additional information.
	4.4. Explicit EOR Marking		4.4. Explicit EOR Marking
	Using explicit EOR marking for an SCTP association supporting user		Using explicit End of Record (EOR) marking for an SCTP association
	message interleaving allows the user to interleave the sending of		supporting user message interleaving allows the user to interleave
	user messages on different streams.		the sending of user messages on different streams.
	5. IANA Considerations		5. IANA Considerations
	[NOTE to RFC-Editor:		[NOTE to RFC-Editor:
	"RFCXXXX" is to be replaced by the RFC number you assign this		"RFCXXXX" is to be replaced by the RFC number you assign this
	document.		document.
	]		]
	skipping to change at page 17, line 10 ¶		skipping to change at page 17, line 10 ¶
	| 0x20 | Unassigned | |		| 0x20 | Unassigned | |
	| 0x40 | Unassigned | |		| 0x40 | Unassigned | |
	| 0x80 | Unassigned | |		| 0x80 | Unassigned | |
	+------------------+-----------------+-----------+		+------------------+-----------------+-----------+
	6. Security Considerations		6. Security Considerations
	This document does not add any additional security considerations in		This document does not add any additional security considerations in
	addition to the ones given in [RFC4960] and [RFC6458].		addition to the ones given in [RFC4960] and [RFC6458].
			It should be noted that the application has to consent that it is
			willing to do the more complex reassembly support required for user
			message interleaving.
	7. Acknowledgments		7. Acknowledgments
	The authors wish to thank Christer Holmberg, Marcelo Ricardo Leitner,		The authors wish to thank Gorry Fairhurst, Christer Holmberg, Marcelo
	Karen E. Egede Nielsen, Irene Ruengeler, Felix Weinrank, and Lixia		Ricardo Leitner, Karen E. Egede Nielsen, Irene Ruengeler, Felix
	Zhang for her invaluable comments.		Weinrank, and Lixia Zhang for her invaluable comments.
	This work has received funding from the European Union's Horizon 2020		This work has received funding from the European Union's Horizon 2020
	research and innovation programme under grant agreement No. 644334		research and innovation programme under grant agreement No. 644334
	(NEAT). The views expressed are solely those of the author(s).		(NEAT). The views expressed are solely those of the author(s).
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
End of changes. 27 change blocks.
	48 lines changed or deleted		71 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/