idnits 2.17.1 draft-natarajan-http-over-sctp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 16 characters in excess of 72. ** The abstract seems to contain references ([RFC2616], [RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2009) is 5406 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1945' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC2116' is defined on line 383, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-19 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-sctpsocket (ref. 'I-D.ietf-tsvwg-sctpsocket') ** Downref: Normative reference to an Informational RFC: RFC 1945 ** Downref: Normative reference to an Informational RFC: RFC 2116 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-01 == Outdated reference: A later version (-07) exists of draft-tuexen-sctp-udp-encaps-02 == Outdated reference: A later version (-08) exists of draft-wood-tae-specifying-uri-transports-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Natarajan 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Amer 5 Expires: January 10, 2010 J. Leighton 6 University of Delaware 7 F. Baker 8 Cisco Systems 9 July 9, 2009 11 Using SCTP as a Transport Layer Protocol for HTTP 12 draft-natarajan-http-over-sctp-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 Hyper-Text Transfer Protocol (HTTP) [RFC2616] requires a reliable 51 transport for end-to-end communication. While historically TCP has 52 been used for this purpose, this document proposes an alternative -- 53 the Stream Control Transmission Protocol (SCTP) [RFC4960]. Similar 54 to TCP, SCTP offers a reliable end-to-end transport connection to 55 applications. Additionally, SCTP offers innovative services 56 unavailable in TCP. This draft (i) specifies HTTP over SCTP's 57 multistreaming service, (ii) lists open issues warranting more 58 discussion and/or investigation, and (iii) shares some lessons 59 learned from implementing HTTP over SCTP. Finally, this document 60 highlights SCTP services that better match HTTP's needs than TCP. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Designing HTTP over SCTP Streams . . . . . . . . . . . . . . . 3 67 3.1. Number of SCTP Streams . . . . . . . . . . . . . . . . . . 4 68 3.2. Mapping HTTP Transactions to SCTP Streams . . . . . . . . 5 69 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Definition of Pipelining . . . . . . . . . . . . . . . . . 5 71 4.2. How does a Web client decide between TCP vs. SCTP? . . . . 6 72 4.3. SCTP and Chunked Encoding . . . . . . . . . . . . . . . . 6 73 4.4. TCP-SCTP Gateway . . . . . . . . . . . . . . . . . . . . . 7 74 4.5. SCTP and Middleboxes . . . . . . . . . . . . . . . . . . . 7 75 5. Lessons Learned from Implementing HTTP over SCTP . . . . . . . 7 76 5.1. Avoiding Dependencies in Message Transmission . . . . . . 7 77 5.2. Order of Pipelined Requests and Responses . . . . . . . . 8 78 5.3. Benefits for Progressive Images . . . . . . . . . . . . . 8 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Appendix A. SCTP Services for HTTP-based Applications . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This draft specifies HTTP over SCTP. SCTP was originally developed 89 to carry telephony signaling messages over IP networks. With 90 continued work, SCTP evolved into a general purpose transport 91 protocol. Similar to TCP, SCTP offers a reliable, full-duplex, 92 congestion and flow-controlled transport connection. Unlike TCP, 93 SCTP offers new services including multistreaming, multihoming, 94 message-oriented data transfer etc. 96 SCTP streams are logically separate data streams within an SCTP 97 "association" (analogous to a TCP connection). Independent HTTP 98 transactions, when transmitted over different SCTP streams, can be 99 delivered to the application without inter-transaction head-of-line 100 (HOL) blocking. This document presents a design for mapping HTTP 101 transactions over SCTP streams, and also highlights ongoing work and 102 open issues that require further discussion and/or investigation 103 within the httpbis community. 105 HTTP over SCTP was implemented in the Apache Server and Firefox 106 browser. Some of the lessons learned during this implementation 107 exercise are discussed. Finally, this document discusses more SCTP 108 services that are better suited to HTTP's needs than TCP services. 110 2. Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Designing HTTP over SCTP Streams 118 In this document, an HTTP request (or response) is considered 119 independent when its application-level processing does not depend on 120 the availability of other HTTP requests (or responses). The primary 121 objective of our design is to exploit SCTP's multistreaming service 122 to avoid HOL blocking between independent HTTP transactions. 124 An SCTP stream is a unidirectional data flow within an SCTP 125 association. Each SCTP stream has its own sequencing space; data 126 arriving in-order within a stream is delivered to the application 127 without regard to the relative order of data arriving on other 128 streams. When independent HTTP transactions are transmitted over 129 different SCTP streams, these transactions are delivered to the 130 application without inter-transaction HOL blocking. 132 Two guidelines govern the HTTP over SCTP streams design discussed 133 below: (i) to reduce deployment concerns, make no changes to the 134 existing HTTP specification (such as the URI syntax), and (ii) 135 minimize SCTP-related state information at the server so that SCTP 136 multistreaming does not further contribute to the server being a 137 performance bottleneck. Detailed discussions on various design 138 decisions can be found in [N2009]. The two components of this design 139 are discussed next. 141 3.1. Number of SCTP Streams 143 SCTP streams are uni-directional; inbound and outbound streams carry 144 data to and from each end point, respectively. The number of inbound 145 or outbound SCTP streams is negotiated during the association 146 establishment phase (Figure 1). Before association establishment, 147 the number of inbound or outbound streams may be modified by using 148 appropriate SCTP socket options [I-D.ietf-tsvwg-sctpsocket]. The 149 stream "reset" functionality allows for re-negotiating the number of 150 streams after association establishment 151 [I-D.stewart-tsvwg-sctpstrrst]. 153 When using SCTP for HTTP, an SCTP association MAY employ any number 154 of inbound or outbound streams (up to 65,536 [RFC4960]). However, 155 for every outbound SCTP stream with id *a* on which the client 156 transmits requests, there MUST be a corresponding inbound stream with 157 id *a*. Typically, this is achieved by opening an SCTP association 158 with equal number of inbound and outbound streams. 160 Client Server 161 | | 162 |-----------INIT (IS=m,OS=m)------------->| 163 #Streams = MIN (m,n) |<---------INIT-ACK (IS=n,OS=n)-----------| #Streams = MIN (m,n) 164 | | 165 / . / 166 \ . \ 167 | | 168 |--------HTTP REQUEST i (on OS a)-------->| 169 |<-------HTTP RESPONSE i (on OS a)--------| 170 | | 171 IS: Inbound Stream 172 OS: Outbound Stream 174 Figure 1: HTTP over SCTP Streams 176 3.2. Mapping HTTP Transactions to SCTP Streams 178 To avoid incurring additional processing overhead at the web server, 179 a web client determines the SCTP stream number on which each HTTP 180 transaction is transmitted. In the example shown in Figure 1, the 181 web client maps HTTP transaction *i* to SCTP stream *a*. The client 182 transmits HTTP request *i* on the client's outbound (server's 183 inbound) SCTP stream *a*. The web server transmits the corresponding 184 response on the server's outbound (client's inbound) SCTP stream *a*. 185 The sctp_sendmsg and sctp_recvmsg APIs, respectively, can be used to 186 transmit data on a particular SCTP outbound stream, and determine the 187 SCTP inbound stream number on which an application message was 188 received. 190 When the number of available SCTP streams is greater than or equal to 191 the number of HTTP transactions, a web client SHOULD NOT pipeline 192 transactions intra-stream, i.e., each HTTP transaction SHOULD be 193 mapped to a different SCTP stream. When the number of available SCTP 194 streams is less than the number of HTTP transactions, the web client 195 MAY either (i) increase the number of SCTP streams in the association 196 [I-D.stewart-tsvwg-sctpstrrst], such that, each transaction is 197 transmitted on a different SCTP stream, or (ii) employ a scheduling 198 policy to pipeline transactions intra-stream. Our implementation 199 employs a round-robin scheduling policy, where HTTP transactions are 200 mapped to available SCTP streams in a round-robin fashion. Other 201 scheduling policies MAY be considered. For example, in a lossy 202 network environment, such as wide area wireless connectivity through 203 GPRS, a better scheduling policy might be 'smallest pending object 204 first' where the next HTTP request goes on the SCTP stream that has 205 the smallest sum of object sizes pending transfer. Such a policy 206 reduces the probability of intra-stream HOL blocking, i.e., HOL 207 blocking between responses downloaded on the same SCTP stream. 209 4. Open Issues 211 This section discusses some of the open issues that require further 212 discussion and/or investigation. 214 4.1. Definition of Pipelining 216 Section 8 of [RFC2616] notes that "HTTP requests and responses can be 217 pipelined on a connection. Pipelining allows a client to make 218 multiple requests without waiting for each response, allowing a 219 single TCP connection to be used much more efficiently, with much 220 lower elapsed time." Adapting this definiton of pipelining to HTTP 221 over SCTP implies that transmitting multiple HTTP requests over an 222 SCTP association (transport connection) without waiting for each 223 response should be considered as pipelining, even if the requests are 224 transmitted on different SCTP streams. Ongoing discussion attempts 225 to figure out if RFC2616's definition of pipelining is generic enough 226 for any transport including SCTP, or if the definition is suitable 227 only for TCP. 229 4.2. How does a Web client decide between TCP vs. SCTP? 231 Web client implementations MUST be aware that an end user or the 232 other end-point (server/proxy) MAY choose to override the client's 233 default choice of transport (TCP vs. SCTP). A web client uses one or 234 more of the following options to decide between TCP vs. SCTP for an 235 HTTP transfer. 237 Option 1: The web client tries in tandem to establish both a TCP 238 connection and an SCTP association to the server. The web client 239 chooses TCP vs. SCTP depending on which transport connection gets 240 established first. This approach is explored in 241 [I-D.wing-http-new-tech]. 243 Option 2: [RFC3263] describes how SIP proxies and clients can select 244 the transport protocol using SRV records [RFC2782]. A similar 245 solution can be conceived for HTTP [H2008]. 247 Option 3: The web client selects TCP vs. SCTP based on the URI. URIs 248 starting with "http://" or "https://" imply TCP and a new URI scheme 249 could be established for similar services over SCTP, such as, 250 "http-sctp://" or "https-sctp://" 251 [I-D.wood-tae-specifying-uri-transports]. 253 While option 1 is simple and end-to-end, the other options require 254 support from new protocols and/or infrastructure. Also, using 255 options 2 and 3, a web client can identify whether the web server 256 supports SCTP but cannot determine if the middleboxes en-route 257 support SCTP (discussed below). 259 4.3. SCTP and Chunked Encoding 261 SCTP's message-based transmission could be leveraged to avoid HTTP's 262 chunked encoding feature. Chunked encoding [RFC2616] allows 263 dynamically generated HTTP messages to be transferred as a series of 264 chunks, each with its own size indicator. The current proposal is to 265 use SCTP's Payload Protocol ID (PPID) -- an optional value set by the 266 sender and read by the receiver, to avoid chunked encoding in HTTP 267 over SCTP. The approach would be to define two new SCTP PPID values 268 (allocated by IANA) -- HTTP_MESSAGE_PIECE and HTTP_MESSAGE_END. The 269 sender sets PPID to HTTP_MESSAGE_PIECE for all but the last chunk of 270 an HTTP object, and sets the last chunk's PPID to HTTP_MESSAGE_END. 272 This proposal is under investigation. 274 4.4. TCP-SCTP Gateway 276 Research has shown that SCTP streams enable perceivable improvements 277 to throughput and web response times, especially in high latency 278 and/or lossy last hops such as satellite links [N2009]. A TCP-SCTP 279 gateway allows web clients in such last hops to experience the 280 benefits of SCTP streams even if the web server runs over TCP. 281 Additionally, the gateway also ensures that web clients connecting to 282 the Internet via the gateway MAY always assume SCTP as the default 283 transport instead of trying to choose between TCP or SCTP as 284 discussed in Section 4.2. Note that web proxies can also function as 285 TCP-SCTP gateways. 287 4.5. SCTP and Middleboxes 289 SCTP's association establishment and multihoming mechanisms pose 290 unique challenges in the context of NATs. These issues are addressed 291 in [I-D.ietf-behave-sctpnat]. The end-to-end path between a client 292 and server MAY consist of one or more NATs and/or firewalls that do 293 not support SCTP. Until middleboxes support SCTP, UDP encapsulation 294 is a possible solution [I-D.tuexen-sctp-udp-encaps]. 296 5. Lessons Learned from Implementing HTTP over SCTP 298 HTTP over SCTP was implemented in the Apache server and Firefox 299 browser at the University of Delaware's Protocol Engineering Lab. 300 Some lessons learned during this experience are discussed below. 301 More details can be found in [N2009]. 303 5.1. Avoiding Dependencies in Message Transmission 305 Similar to UDP, SCTP preserves message boundaries and employs a 306 fragmentation and reassembly algorithm to accomplish this. SCTP's 307 fragmentation and reassembly algorithm creates dependencies in 308 message transmission, i.e., a fragment of message i+1 cannot be 309 transmitted until all fragments of message i have been transmitted. 310 If messages i and i+1 are of sizes 100KB and 1KB, respectively, the 311 100KB message transmission can unnecessarily delay transmission of 312 the 1KB message. The client or server application can avoid this 313 delay by splitting each HTTP request or response into multiple 314 messages, such that, each message at the SCTP layer results in a 315 PMTU-sized SCTP PDU, thus requiring no further fragmentation by SCTP. 316 An application can use either the SCTP_PEER_ADDR or the SCTP_STATUS 317 socket options to obtain an SCTP association's PMTU 318 [I-D.ietf-tsvwg-sctpsocket]. 320 5.2. Order of Pipelined Requests and Responses 322 Section 8 of [RFC2616] mandates that in HTTP 1.1 with pipelining, "a 323 server MUST send its responses to those requests in the same order 324 that the requests were received." Since TCP always delivers data in- 325 order, the order of HTTP requests received by the server, and 326 therefore, the order of HTTP responses generated by the server match 327 the order of transmitted HTTP requests from the client. 328 Consequently, a web client can assume that, within a TCP connection, 329 the order of HTTP responses from the server always matches the order 330 of transmitted HTTP requests. Unlike TCP, SCTP's multistreaming 331 feature delivers out-of-order data at both the server and client. 332 When HTTP requests from client to server are lost, requests 333 transmitted over different SCTP streams will be delivered out-of- 334 order at the server, and therefore, the order of generated HTTP 335 responses will be different from the order of transmitted HTTP 336 requests. Also, the loss of an HTTP response will affect the order 337 of HTTP responses from the server. Our experience with the FreeBSD 338 SCTP implementation revealed that HTTP requests and responses can be 339 received out-of-order even under no loss conditions [N2009]. 340 Therefore, web client implementations MUST be aware that within an 341 SCTP assocation, the order of pipelined responses from the server may 342 not match the order of transmitted HTTP reqeusts. However, in case 343 of intra-stream pipelining, the order of HTTP responses within an 344 inbound SCTP stream *a* MUST match the order of transmitted HTTP 345 requests within the corresponding outbound SCTP stream *a*. 346 Consequently, within each SCTP stream, a web server MUST send its 347 responses to those reqeusts in the same order that the requests were 348 received. 350 5.3. Benefits for Progressive Images 352 Progressive images (e.g., JPEG, PNG) are coded such that the initial 353 bytes approximate the entire image, and successive bytes gradually 354 improve the image's quality/resolution. Simple experiments have 355 shown that user-perceived response time improvements for HTTP 356 transfers consisting of progressive images are more significant than 357 for similar transfers consisting of non-progressive images. When 358 each progressive image is downloaded on a different SCTP stream, the 359 Firefox implementation over FreeBSD SCTP renders a good quality 360 version of each progressive image significantly earlier than the page 361 download time [NAS2008]. These page downloads were captured as 362 movies and can be viewed at [Movies]. 364 6. Acknowledgments 366 Thanks to Henrik Nordstorm, Dan Wing, and Andrew Yourtchenko for 367 helping with the Open Issues Section. 369 7. References 371 7.1. Normative References 373 [I-D.ietf-tsvwg-sctpsocket] 374 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 375 Lei, "Sockets API Extensions for Stream Control 376 Transmission Protocol (SCTP)", 377 draft-ietf-tsvwg-sctpsocket-19 (work in progress), 378 February 2009. 380 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 381 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 383 [RFC2116] Apple, C. and K. Rossen, "X.500 Implementations 384 Catalog-96", RFC 2116, April 1997. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 390 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 391 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 393 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 394 RFC 4960, September 2007. 396 7.2. Informative References 398 [FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME_WAIT state in 399 TCP and its effect on busy servers", INFOCOM '99: 400 Proceedings of the IEEE INFOCOM Conference, pp. 1573- 401 1583 , 1999. 403 [H2008] Hardie, T., "Email Post to the APPS-DISCUSS Mailing List", 404 (work in progress) , 2008. 406 [I-D.ietf-behave-sctpnat] 407 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 408 Transmission Protocol (SCTP) Network Address Translation", 409 draft-ietf-behave-sctpnat-01 (work in progress), 410 February 2009. 412 [I-D.stewart-tsvwg-sctpstrrst] 413 Stewart, R., Lei, P., and M. Tuexen, "Stream Control 414 Transmission Protocol (SCTP) Stream Reconfiguration", 415 draft-stewart-tsvwg-sctpstrrst-01 (work in progress), 416 February 2009. 418 [I-D.tuexen-sctp-udp-encaps] 419 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 420 Packets", draft-tuexen-sctp-udp-encaps-02 (work in 421 progress), November 2007. 423 [I-D.wing-http-new-tech] 424 Wing, D., Yourtchenko, A., and P. Natarajan, "Happy 425 Eyeballs: Successful Introduction of New Technology to 426 HTTP", (work in progress) , 2009. 428 [I-D.wood-tae-specifying-uri-transports] 429 Wood, L., "Specifying transport mechanisms in Uniform 430 Resource Identifiers", 431 draft-wood-tae-specifying-uri-transports-06 (work in 432 progress), May 2009. 434 [Movies] "Movies Comparing HTTP over TCP vs. HTTP over SCTP 435 Streams", 2008, . 438 [N2009] Natarajan, P., "Leveraging Innovative Transport Layer 439 Services for Improved Application Performance", PhD 440 Dissertation, Computer & Information Sciences Department, 441 University of Delaware, USA , 2009. 443 [NAS2008] Natarajan, P., Amer, P., and R. Stewart, "Multistreamed 444 Web Transport for Developing Regions", NSDR '08: 445 Proceedings of the second ACM SIGCOMM workshop on 446 Networked systems for developing regions, Seattle, WA, 447 USA , 2008. 449 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 450 RFC 793, September 1981. 452 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 453 specifying the location of services (DNS SRV)", RFC 2782, 454 February 2000. 456 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 457 Protocol (SIP): Locating SIP Servers", RFC 3263, 458 June 2002. 460 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 461 Conrad, "Stream Control Transmission Protocol (SCTP) 462 Partial Reliability Extension", RFC 3758, May 2004. 464 Appendix A. SCTP Services for HTTP-based Applications 466 This draft discussed how SCTP's multistreaming and message-based 467 transmission could be adapted for HTTP. This section lists other 468 SCTP services. The authors believe that the SCTP services listed 469 below MAY help HTTP, but the details remain unclear at this time. 471 1. Four-way Handshake during Association Establishment. 473 To protect an end host from SYN-flooding DoS attacks, SCTP's 474 association establishment involves a four-way handshake with a 475 cookie mechanism. Since data transfer can begin in the third 476 leg, the four-way handshake does not delay data transmission any 477 further than TCP's three-way handshake for connection 478 establishment. 480 2. No Maximum Segment Lifetime (MSL) during Association Termination. 482 SCTP's association termination does not involve a TIME_WAIT state 483 [RFC0793], since the Initiation and Verification tags help to 484 associate SCTP Protocol Data Units (PDUs) with the corresponding 485 SCTP associations [RFC4960]. Note that TCP's TIME_WAIT state 486 increases memory and processing overload at a busy web server 487 [FTY1999]. 489 3. SCTP Multihoming for Improved Fault Tolerance. 491 Unlike TCP and UDP, an SCTP association can bind multiple IP 492 addresses at each peer. While an SCTP sender transmits data to a 493 single primary destination IP address, the sender concurrently 494 tracks the reachability of other destination addresses for fault- 495 tolerance purposes. If the primary address becomes unreachable, 496 an SCTP sender seamlessly migrates data transmission to an 497 alternate active destination address. Multihomed clients and/or 498 web servers will automatically benefit from greater fault- 499 tolreance by using SCTP. 501 4. Partial Reliability. 503 Reference [RFC3758] describes PR-SCTP, an extenstion to 504 [RFC4960], that enables partially reliable data transfer between 505 a PR-SCTP sender and receiver. In TCP and plain SCTP, all 506 transmitted data are guaranteed to be delivered. Alternatively, 507 PR-SCTP gives an application the flexibility to notify how 508 persistent the transport sender should be in trying to 509 communicate a particular message to the receiver. An application 510 MAY specify a "lifetime" for each message. A PR-SCTP sender 511 tries to transmit the message during this lifetime. Upon 512 lifetime expiration, a PR-SCTP sender discards the message 513 irrespective of whether or not the message was successfully 514 transmitted and/or acknowledged. This timed reliability in data 515 transfer may be useful in applications that regularly generate 516 new data that obsoletes earlier data, for example, online gaming 517 application in which a player frequently generates new position 518 coordinates or other data with ephemeral significance. The 519 proposed HTTP over SCTP design in Section 3 currently does not 520 make use of this PR-SCTP service. 522 5. Unordered Data Delivery. 524 Similar to UDP and unlike TCP, SCTP offers unordered data 525 delivery service. An application message, marked for unordered 526 delivery, is delivered to the receiving application as soon as 527 the message arrives at the SCTP receiver. Unlike UDP, SCTP 528 provides reliability for unordered data. Note that a single SCTP 529 association can transfer both ordered and unordered messages. 530 The proposed HTTP over SCTP design in Section 3 does not make use 531 of this SCTP service. 533 Authors' Addresses 535 Preethi Natarajan 536 Cisco Systems 537 425 East Tasman Drive 538 San Jose, CA 95134 539 USA 541 Phone: 542 Email: prenatar@cisco.com 543 Paul D. Amer 544 University of Delaware 545 Computer and Information Sciences Department 546 Newark, DE 19716 547 USA 549 Phone: 302-831-1944 550 Email: amer@cis.udel.edu 552 Jonathan Leighton 553 University of Delaware 554 Computer and Information Sciences Department 555 Newark, DE 19716 556 USA 558 Phone: 559 Email: leighton@cis.udel.edu 561 Fred Baker 562 Cisco Systems 563 1121 Via Del Rey 564 Santa Barbara, CA 93117 565 USA 567 Phone: 568 Email: fred@cisco.com