idnits 2.17.1
draft-dreibholz-tsvwg-sctp-nextgen-ideas-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 04, 2014) is 3584 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 4960 (ref. '8') (Obsoleted by RFC 9260)
** Obsolete normative reference: RFC 6096 (ref. '12') (Obsoleted by RFC
9260)
** Obsolete normative reference: RFC 7053 (ref. '16') (Obsoleted by RFC
9260)
== Outdated reference: A later version (-27) exists of
draft-tuexen-tsvwg-sctp-multipath-08
== Outdated reference: A later version (-37) exists of
draft-hohendorf-secure-sctp-17
== Outdated reference: A later version (-13) exists of
draft-ietf-rtcweb-data-channel-10
Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group T. Dreibholz
3 Internet-Draft Simula Research Laboratory
4 Intended status: Informational July 04, 2014
5 Expires: January 5, 2015
7 Ideas for a Next Generation of the Stream Control Transmission Protocol
8 (SCTP)
9 draft-dreibholz-tsvwg-sctp-nextgen-ideas-00.txt
11 Abstract
13 This document collects some ideas for a next generation of the Stream
14 Control Transmission Protocol (SCTP) for further discussion. It is a
15 result of lessons learned from more than one decade of SCTP
16 deployment.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on January 5, 2015.
35 Copyright Notice
37 Copyright (c) 2014 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 This document may contain material from IETF Documents or IETF
51 Contributions published or made publicly available before November
52 10, 2008. The person(s) controlling the copyright in some of this
53 material may not have granted the IETF Trust the right to allow
54 modifications of such material outside the IETF Standards Process.
55 Without obtaining an adequate license from the person(s) controlling
56 the copyright in such materials, this document may not be modified
57 outside the IETF Standards Process, and derivative works of it may
58 not be created outside the IETF Standards Process, except to format
59 it for publication as an RFC or to translate it into languages other
60 than English.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
65 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2
66 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2
67 1.3. Stream Control Transmission Protocol . . . . . . . . . . 2
68 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 2. What to Change in the Next Generation of SCTP? . . . . . . . 3
70 2.1. Security Considerations . . . . . . . . . . . . . . . . . 4
71 2.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 4
72 3. Experimental Implementations . . . . . . . . . . . . . . . . 4
73 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 4
74 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
76 6.1. Normative References . . . . . . . . . . . . . . . . . . 4
77 6.2. Informative References . . . . . . . . . . . . . . . . . 6
78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
80 1. Introduction
82 1.1. Abbreviations
84 o SCTP: Stream Control Transmission Protocol
86 1.2. Conventions
88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
90 document are to be interpreted as described in [1].
92 1.3. Stream Control Transmission Protocol
94 The Stream Control Transmission Protocol (SCTP) has been defined as
95 RFCs in [2], [3], [4], [5], [6], [7], [8], [9], [11], [12], [13],
96 [14], [15], [16]. There is also a detailed introduction provided by
98 [23] as well as lots of further information material on [20]. SCTP
99 is therefore not introduced in more detail here.
101 1.4. Scope
103 The scope of this document is to collect some ideas of what to update
104 /change for a next generation of the SCTP protocol. It is a result
105 of lessons learned from more than one decade of SCTP deployment (see
106 also [23]) as well as ongoing discussions on applying SCTP for WebRTC
107 Data Channels (as introduced in more detail in [19]).
109 2. What to Change in the Next Generation of SCTP?
111 o Make useful extensions part of the next generation core protocol
112 itself (that is, make their implementation a MUST):
114 * Partial Reliablility ([5])
116 * Chunk Authentication ([7])
118 * Partial Reliablility ([9])
120 * Stream Reconfiguration ([14])
122 * SACK Immediately ([16])
124 o Consider additional features as part of the next generation core
125 protocol:
127 * Non-Renegable Selective Acknowledgments (NR-SACK) ([25])
129 * Concurrent Multi-Path Transfer for SCTP (CMT-SCTP) ([17])
131 o Chunk Authentication provides integrity but not confidentiality.
132 There could be a feature for encryption as well, for example like
133 [18]. Having encryption directly included inside the core
134 transport protocol may make it easier to use (less error-prone
135 work for application developers).
137 o SCTP assigns a fixed TSN per DATA chunk. The TSN cannot be
138 changed any more. That is, it is not possible for a middlebox to
139 split chunks into smaller pieces (for example, for hardware
140 offloading). For further discussion: may it be useful to consider
141 a different behavior?
143 o Definition of path: For SCTP, a path is defined by a remote
144 destination address. [21], [22] shows that CMT-SCTP performance
145 also depends on the local endpoint's outgoing links. Considering
146 each pair of local outgoing and remote incoming address as
147 different path may lead to improved performance in many Internet
148 scenarios.
150 2.1. Security Considerations
152 Security considerations for SCTP can be found in [10].
154 2.2. IANA Considerations
156 This document introduces no additional considerations for IANA.
158 3. Experimental Implementations
160 An Open Source simulation model for SCTP is available for OMNeT++
161 within the INET Framework. See [24] for the Git repository. For
162 documentation on the model, see [26] and [23]. This model can be
163 used to evaluate future ideas for SCTP.
165 4. Testbed Platform
167 NorNet is a large-scale and realistic Internet testbed platform with
168 support for multi-homing. A description of and introduction to
169 NorNet is provided in [27], [28], [29], [30]. Further information
170 can be found on the project website [31] at https://www.nntb.no.
172 5. Acknowledgments
174 The author would like to thank Martin Becke for discussions and
175 support.
177 6. References
179 6.1. Normative References
181 [1] Bradner, S., "Key words for use in RFCs to Indicate
182 Requirement Levels", BCP 14, RFC 2119, March 1997.
184 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
185 Loughney, J., and M. Stillman, "Requirements for Reliable
186 Server Pooling", RFC 3237, January 2002.
188 [3] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
189 Layer Security over Stream Control Transmission Protocol",
190 RFC 3436, December 2002.
192 [4] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
193 Stewart, "On the Use of Stream Control Transmission
194 Protocol (SCTP) with IPsec", RFC 3554, July 2003.
196 [5] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
197 Conrad, "Stream Control Transmission Protocol (SCTP)
198 Partial Reliability Extension", RFC 3758, May 2004.
200 [6] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
201 Parameter for the Stream Control Transmission Protocol
202 (SCTP)", RFC 4820, March 2007.
204 [7] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
205 "Authenticated Chunks for the Stream Control Transmission
206 Protocol (SCTP)", RFC 4895, August 2007.
208 [8] Stewart, R., "Stream Control Transmission Protocol", RFC
209 4960, September 2007.
211 [9] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
212 Kozuka, "Stream Control Transmission Protocol (SCTP)
213 Dynamic Address Reconfiguration", RFC 5061, September
214 2007.
216 [10] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M.
217 Holdrege, "Threats Introduced by Reliable Server Pooling
218 (RSerPool) and Requirements for Security in Response to
219 Threats", RFC 5355, September 2008.
221 [11] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
222 Transport Layer Security (DTLS) for Stream Control
223 Transmission Protocol (SCTP)", RFC 6083, January 2011.
225 [12] Tuexen, M. and R. Stewart, "Stream Control Transmission
226 Protocol (SCTP) Chunk Flags Registration", RFC 6096,
227 January 2011.
229 [13] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
230 Yasevich, "Sockets API Extensions for the Stream Control
231 Transmission Protocol (SCTP)", RFC 6458, December 2011.
233 [14] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
234 Transmission Protocol (SCTP) Stream Reconfiguration", RFC
235 6525, February 2012.
237 [15] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
238 Control Transmission Protocol (SCTP) Packets for End-Host
239 to End-Host Communication", RFC 6951, May 2013.
241 [16] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
242 IMMEDIATELY Extension for the Stream Control Transmission
243 Protocol", RFC 7053, November 2013.
245 [17] Amer, P., Becke, M., Dreibholz, T., Ekiz, N., Jana, J.,
246 Natarajan, P., Stewart, R., and M. Tuexen, "Load Sharing
247 for the Stream Control Transmission Protocol (SCTP)",
248 draft-tuexen-tsvwg-sctp-multipath-08 (work in progress),
249 March 2014.
251 [18] Hohendorf, C., Unurkhaan, E., and T. Dreibholz, "Secure
252 SCTP", draft-hohendorf-secure-sctp-17 (work in progress),
253 January 2014.
255 [19] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
256 Channels", draft-ietf-rtcweb-data-channel-10 (work in
257 progress), June 2014.
259 6.2. Informative References
261 [20] Dreibholz, T., "Thomas Dreibholz's SCTP Page", Online:
262 http://www.iem.uni-due.de/~dreibh/sctp/, 2013,
263 .
265 [21] Becke, M., Adhari, H., Rathgeb, E., Fa, F., Yang, X., and
266 X. Zhou, "Comparison of Multipath TCP and CMT-SCTP based
267 on Intercontinental Measurements", Proceedings of the IEEE
268 Global Communications Conference (GLOBECOM), December
269 2013, .
272 [22] Adhari, H., "Practical Experiences with an Inter-
273 Continental Testbed for Multi-Path Transport", Proceedings
274 of the 1st International NorNet Users Workshop (NNUW-1),
275 September 2013, .
278 [23] Dreibholz, T., "Evaluation and Optimisation of Multi-Path
279 Transport using the Stream Control Transmission Protocol",
280 March 2012, .
284 [24] Varga, A., "INET Framework for OMNeT++", 2014,
285 .
287 [25] Natarajan, P., Ekiz, N., Yilmaz, E., Amer, P., and J.
288 Iyengar, "Non-Renegable Selective Acknowledgments (NR-
289 SACKs) for SCTP", Proceedings of the 16th IEEE
290 International Conference on Network Protocols (ICNP) Pages
291 187-196, ISBN 978-1-4244-2506-8, DOI 10.1109/
292 ICNP.2008.4697037, October 2008,
293 .
296 [26] Ruengeler, I., "SCTP - Evaluating, Improving and Extending
297 the Protocol for Broader Deployment", December 2009,
298 .
301 [27] Gran, E., Dreibholz, T., and A. Kvalbein, "NorNet Core - A
302 Multi-Homed Research Testbed", Computer Networks, Special
303 Issue on Future Internet Testbeds, 2014.
305 [28] Dreibholz, T. and E. Gran, "Design and Implementation of
306 the NorNet Core Research Testbed for Multi-Homed Systems",
307 Proceedings of the 3nd International Workshop on Protocols
308 and Applications with Multi-Homing Support (PAMS), Pages
309 1094-1100, ISBN 978-0-7695-4952-1, DOI 10.1109/
310 WAINA.2013.71, March 2013, .
314 [29] Dreibholz, T., "The NorNet Core Testbed - Introduction and
315 Status", Proceedings of the 1st International NorNet Users
316 Workshop (NNUW-1), September 2013, .
319 [30] Dreibholz, T., "The NorNet Core Testbed - An Experiment
320 Tutorial", Proceedings of the 1st International NorNet
321 Users Workshop (NNUW-1), September 2013, .
324 [31] Dreibholz, T., "NorNet -- A Real-World, Large-Scale Multi-
325 Homing Testbed", Online: https://www.nntb.no/, 2014,
326 .
328 Author's Address
329 Thomas Dreibholz
330 Simula Research Laboratory, Network Systems Group
331 Martin Linges vei 17
332 1364 Fornebu, Akershus
333 Norway
335 Phone: +47-6782-8200
336 Fax: +47-6782-8201
337 Email: dreibh@simula.no
338 URI: http://www.iem.uni-due.de/~dreibh/