idnits 2.17.1 draft-natarajan-httpbis-sctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. 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 ([RFC2116], [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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5632 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) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-17 ** 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 (-01) exists of draft-stewart-tsvwg-sctpstrrst-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Natarajan 3 Internet-Draft P. Amer 4 Intended status: Standards Track J. Leighton 5 Expires: April 30, 2009 University of Delaware 6 F. Baker 7 Cisco Systems 8 October 27, 2008 10 Using SCTP as a Transport Layer Protocol for HTTP 11 draft-natarajan-httpbis-sctp-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 30, 2009. 38 Abstract 40 Hyper-Text Transfer Protocol (HTTP) [RFC2116] requires a reliable 41 transport for end-to-end communication. While historically TCP has 42 been used for this purpose, this document proposes an alternative -- 43 the Stream Control Transmission Protocol (SCTP) [RFC4960]. Similar 44 to TCP, SCTP offers a reliable end-to-end transport connection to 45 applications. Additionally, SCTP offers other innovative services 46 unavailable in TCP. The objectives of this draft are three-fold: (i) 47 to highlight SCTP services that better match HTTP's needs than TCP, 48 (ii) to propose a design for persistent and pipelined HTTP 1.1 49 transactions over SCTP's multistreaming service, and (iii) to share 50 some lessons learned from implementing HTTP over SCTP. Finally, open 51 issues warranting more discussion and/or investigation are listed. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. SCTP Services for HTTP-based Applications . . . . . . . . . . 3 58 4. Designing HTTP over SCTP Streams . . . . . . . . . . . . . . . 5 59 4.1. Number of SCTP Streams . . . . . . . . . . . . . . . . . . 7 60 4.2. Mapping HTTP Transactions to SCTP Streams . . . . . . . . 7 61 5. Lessons Learned from Implementing HTTP over SCTP . . . . . . . 8 62 5.1. Avoiding Dependencies in Message Transmission . . . . . . 8 63 5.2. Order of Pipelined Requests and Responses . . . . . . . . 8 64 5.3. Benefits for Progressive Images . . . . . . . . . . . . . 9 65 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. How does a Web client decide between TCP vs. SCTP? . . . . 10 67 6.2. TCP-SCTP Gateway . . . . . . . . . . . . . . . . . . . . . 10 68 6.3. SCTP and NATs . . . . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 SCTP was originally developed to carry telephony signaling messages 79 over IP networks. With continued work, SCTP evolved into a general 80 purpose transport protocol. Similar to TCP, SCTP offers a reliable, 81 full-duplex, congestion and flow-controlled transport connection. 82 Unlike TCP, SCTP offers other innovative services including 83 multistreaming, multihoming, partial-realiability, and message- 84 oriented data transfer. This document highlights some of the SCTP 85 services that are better suited to HTTP's needs than TCP services. 87 SCTP's multistreaming service is perhaps the most beneficial SCTP 88 service for HTTP. SCTP streams are logically separate data streams 89 within an SCTP "association" (analogous to a TCP connection). 90 Independent HTTP transactions, when transmitted over different SCTP 91 streams, can be delivered to the application without inter- 92 transaction head-of-line (HOL) blocking. Emulation results show that 93 SCTP streams eliminate HOL blocking and significantly improve web 94 response times [N2008]. This document presents our design for 95 persistent and pipelined HTTP 1.1 transactions over SCTP streams, and 96 some of the lessons learned from implementing this design in the 97 Apache server and Firefox browser. 99 Finally, this document lists some of the open issues that require 100 further discussion and/or investigation within the httpbis community. 102 2. Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. SCTP Services for HTTP-based Applications 110 Similar to TCP, SCTP provides a reliable and in-order data transfer 111 service to HTTP. Additionally, SCTP provides other services 112 unavailable in TCP. These services are summarized below. The HTTP 113 over SCTP design proposed in Section 4 utilizes only a subset of 114 these SCTP services. The authors believe that other SCTP services 115 listed below MAY help HTTP, but the details remain unclear at this 116 time. 118 1. SCTP Multistreaming Avoids Head-of-Line (HOL) Blocking. 120 An SCTP stream is a unidirectional data flow within an SCTP 121 association. Each SCTP stream has its own sequencing space; data 122 arriving in-order within a stream is delivered to the application 123 without regard to the relative order of data arriving on other 124 streams. When independent HTTP transactions are transmitted over 125 different SCTP streams, these transactions are delivered to the 126 application without inter-transactoin HOL blocking. Section 4 127 discusses the benefits of HTTP over SCTP streams in more detail. 129 2. Four-way Handshake during Association Establishment. 131 To protect an end host from SYN-flooding DoS attacks, SCTP's 132 association establishment involves a four-way handshake with a 133 cookie mechanism. Since data transfer can begin in the third 134 leg, the four-way handshake does not delay data transmission any 135 further than TCP's three-way handshake for connection 136 establishment. 138 3. No Maximum Segment Lifetime (MSL) during Association Termination. 140 SCTP's association termination does not involve a TIME_WAIT state 141 [RFC0793], since the Initiation and Verification tags help to 142 associate SCTP Protocol Data Units (PDUs) with the corresponding 143 SCTP associations [RFC4960]. Note that TCP's TIME_WAIT state 144 increases memory and processing overload at a busy web server 145 [FTY1999]. 147 4. SCTP Multihoming for Improved Fault Tolerance. 149 Unlike TCP and UDP, an SCTP association can bind multiple IP 150 addresses at each peer. While an SCTP sender transmits data to a 151 single primary destination IP address, the sender concurrently 152 tracks the reachability of other destination addresses for fault- 153 tolerance purposes. If the primary address becomes unreachable, 154 an SCTP sender seamlessly migrates data transmission to an 155 alternate active destination address. Multihomed clients and/or 156 web servers will automatically benefit from greater fault- 157 tolreance by using SCTP. 159 5. Preserving Application Message Boundaries. 161 Similar to UDP, SCTP offers message-oriented data transfer. SCTP 162 preserves application message boundaries; messages are delivered 163 in their entirety to the receiving application. Applications 164 using SCTP do not require explicit message delimiters, which 165 simplifies message parsing. However, the advantages of SCTP's 166 message-oriented data transmission service to HTTP is unclear, 167 and the proposed HTTP over SCTP design in Section 4 does not 168 exploit this SCTP service. To preserve message boundaries, SCTP 169 employs a fragmentation and reassemebly algorithm. This 170 algorithm creates dependencies in message transmission, discussed 171 further in Section 5.1, [N2008]. 173 6. Partial Reliability. 175 Reference [RFC3758] describes PR-SCTP, an extenstion to 176 [RFC4960], that enables partially reliable data transfer between 177 a PR-SCTP sender and receiver. In TCP and plain SCTP, all 178 transmitted data are guaranteed to be delivered. Alternatively, 179 PR-SCTP gives an application the flexibility to notify how 180 persistent the transport sender should be in trying to 181 communicate a particular message to the receiver. An application 182 MAY specify a "lifetime" for each message. A PR-SCTP sender 183 tries to transmit the message during this lifetime. Upon 184 lifetime expiration, a PR-SCTP sender discards the message 185 irrespective of whether or not the message was successfully 186 transmitted and/or acknowledged. This timed reliability in data 187 transfer may be useful in applications that regularly generate 188 new data that obsoletes earlier data, for example, online gaming 189 application in which a player frequently generates new position 190 coordinates or other data with ephemeral significance. The 191 proposed HTTP over SCTP design in Section 4 currently does not 192 make use of this PR-SCTP service. 194 7. Unordered Data Delivery. 196 Similar to UDP and unlike TCP, SCTP offers unordered data 197 delivery service. An application message, marked for unordered 198 delivery, is delivered to the receiving application as soon as 199 the message arrives at the SCTP receiver. Unlike UDP, SCTP 200 provides reliability for unordered data. Note that a single SCTP 201 association can transfer both ordered and unordered messages. 202 The proposed HTTP over SCTP design in Section 4 does not make use 203 of this SCTP service. 205 4. Designing HTTP over SCTP Streams 207 In this document, an HTTP GET request (or response) is considered 208 independent when its application-level processing does not depend on 209 the availability of other HTTP GET requests (or responses). The 210 primary objective of our design is to exploit SCTP's multistreaming 211 service to avoid HOL blocking between independent HTTP transactions. 213 Note that HTTP transctions do not experience HOL blocking when either 214 (i) each HTTP transaction is transmitted over a different TCP 215 connection (HTTP 1.0) [RFC1945], or (ii) multiple HTTP transactions 216 are transmitted in a non-pipelined fashion over a single persistent 217 TCP connection [RFC2616]. Consequently, we do not expect SCTP's 218 multistreaming to improve response times for an HTTP 1.0 transfer or 219 a non-pipelined HTTP 1.1 transfer. Nonetheless, these HTTP transfers 220 may benefit from other SCTP features such as multihoming, four-way 221 association establishment handshake etc., mentioned in Section 3. 222 Note that a client or server implementing HTTP 1.0 or non-pipelined 223 HTTP 1.1 over TCP can be trivially mapped to work over SCTP by 224 creating an SCTP socket instead of a TCP socket 225 [I-D.ietf-tsvwg-sctpsocket]. 227 An HTTP transaction may be HOL blocked by another independent HTTP 228 transaction only when these transactions are transmitted in a 229 pipelined fashion over a single TCP connection. Transferring these 230 transactions over different streams of a single SCTP association 231 elimiates the inter-transaction HOL blocking. Emulation results show 232 that persistent and pipelined HTTP 1.1 transfers over a single 233 multistreamed SCTP association experience better response times when 234 compared to similar transfers over a single TCP connection. The 235 difference in TCP vs. SCTP response times increases and is more 236 visually perceivable in high latency and lossy browsing conditions, 237 such as those found in the developing world [NAS2008]. 239 Apart from improving response times, SCTP streams may also reduce 240 setup and memory costs at a web server/cache/proxy. To reduce HOL 241 blocking, web clients open muliple TCP connections to download 242 independent HTTP transactions from the same server. In contrast, a 243 web client using SCTP eliminates HOL blocking by simply increasing 244 the number of streams within a single SCTP association. Each TCP 245 connection or SCTP stream incurs additional setup and memory overhead 246 at both the client and server. However, the costs associated with a 247 new SCTP stream are in general lower than those associated with a new 248 TCP connection, and the cost gains from using SCTP increase as the 249 number of web clients increase. The exact difference in TCP vs. SCTP 250 resource requirements depends on the respective protocol 251 implementations [N2008]. 253 Two guidelines govern the HTTP over SCTP streams design discussed 254 below: (i) make no changes to the existing HTTP specification (such 255 as the URI syntax), to reduce deployment issues, and (ii) minimize 256 SCTP-related state information at the server so that SCTP 257 multistreaming does not further contribute to the server being a 258 performance bottleneck. Detailed discussions on various design 259 decisions can be found in [N2008]. The two components of this design 260 are discussed next. 262 4.1. Number of SCTP Streams 264 SCTP streams are uni-directional; inbound and outbound streams carry 265 data to and from each end point, respectively. Each inbound or 266 outbound stream incurs additional memory overhead in the SCTP 267 Protocol Control Block, and this overhead depends on the SCTP 268 implementation. The number of inbound or outbound SCTP streams is 269 negotiated during the association establishment phase (Figure 1). 270 Before association establishment, the number of inbound or outbound 271 streams may be modified by using appropriate SCTP socket options 272 [I-D.ietf-tsvwg-sctpsocket]. The stream "reset" functionality allows 273 for re-negotiating the number of streams after association 274 establishment [I-D.stewart-tsvwg-sctpstrrst]. When using SCTP for 275 HTTP, an SCTP association MAY employ any number of inbound or 276 outbound streams (up to 65,536 [RFC4960]). However, for every 277 outbound SCTP stream with id *a* on which the client transmits 278 requests, there MUST be a corresponding inbound stream with id *a*. 279 Typically, this is achieved by opening an SCTP association with equal 280 number of inbound and outbound streams. 282 Client Server 283 | | 284 |-----------INIT (IS=m,OS=m)------------->| 285 #Streams = MIN (m,n) |<---------INIT-ACK (IS=n,OS=n)-----------| #Streams = MIN (m,n) 286 | | 287 / . / 288 \ . \ 289 | | 290 |----------HTTP GET i (on OS a)---------->| 291 |<---------HTTP RES i (on OS a)-----------| 292 | | 293 IS: Inbound Stream 294 OS: Outbound Stream 296 Figure 1: HTTP over SCTP Streams 298 4.2. Mapping HTTP Transactions to SCTP Streams 300 To avoid incurring additional processing overhead at the web server, 301 a web client determines the SCTP stream number on which each HTTP 302 transaction is transmitted. In the example shown in Figure 1, the 303 web client maps HTTP transaction *i* to SCTP stream *a*. The client 304 transmits HTTP request *i* on the client's outbound (server's 305 inbound) SCTP stream *a*. The web server transmits the corresponding 306 response on the server's outbound (client's inbound) SCTP stream *a*. 308 The sctp_sendmsg and sctp_recvmsg APIs, respectively, can be used to 309 transmit data on a particular SCTP outbound stream, and determine the 310 SCTP inbound stream number on which an application message was 311 received. 313 When the number of available SCTP streams is greater than or equal to 314 the number of HTTP transactions, a web client SHOULD NOT pipeline 315 transactions intra-stream, i.e., each HTTP transaction SHOULD be 316 mapped to a different SCTP stream. When the number of available SCTP 317 streams is less than the number of HTTP transactions, the web client 318 MAY employ a scheduling policy to pipeline transactions intra-stream. 319 Our implementation employs a round-robin scheduling policy, where 320 HTTP transactions are mapped to available SCTP streams in a round- 321 robin fashion. Other scheduling policies MAY be considered. For 322 example, in a lossy network environment, such as wide area wireless 323 connectivity through GPRS, a better scheduling policy might be 324 'smallest pending object first' where the next GET request goes on 325 the SCTP stream that has the smallest sum of object sizes pending 326 transfer. Such a policy reduces the probability of intra-stream HOL 327 blocking, i.e., HOL blocking between responses downloaded on the same 328 SCTP stream. 330 5. Lessons Learned from Implementing HTTP over SCTP 332 HTTP over SCTP was implemented in the Apache server and Firefox 333 browser at the University of Delaware's Protocol Engineering Lab. 334 Some lessons learned during this experience are discussed below. 335 More details can be found in [N2008]. 337 5.1. Avoiding Dependencies in Message Transmission 339 SCTP's fragmentation and reassembly algorithm creates dependencies in 340 message transmission, i.e., a fragment of message i+1 cannot be 341 transmitted until all fragments of message i have been transmitted. 342 If messages i and i+1 are of sizes 100KB and 1KB respectively, the 343 100KB message transmission can unnecessarily block transmission of 344 the 1KB message. The client or server application can overcome this 345 by splitting each HTTP request or response into multiple messages, 346 such that, each message at the SCTP layer results in a PMTU-sized 347 SCTP PDU, and is not fragmented further by SCTP. An application can 348 use either the SCTP_PEER_ADDR or the SCTP_STATUS socket options to 349 obtain an SCTP association's PMTU [I-D.ietf-tsvwg-sctpsocket]. 351 5.2. Order of Pipelined Requests and Responses 353 Section 8 of [RFC2616] mandates that in HTTP 1.1 with pipelining, "a 354 server MUST send its responses to those requests in the same order 355 that the requests were received." Since TCP always delivers data in- 356 order, the order of HTTP requests received by the server, and 357 therefore, the order of HTTP responses generated by the server match 358 the order of transmitted HTTP requests from the client. 359 Consequently, a web client can assume that, within a TCP connection, 360 the order of HTTP responses from the server always matches the order 361 of transmitted HTTP requests. Unlike TCP, SCTP's multistreaming 362 feature delivers out-of-order data at both the server and client. 363 When HTTP requests from client to server are lost, requests 364 transmitted over different SCTP streams will be delivered out-of- 365 order at the server, and therefore, the order of generated HTTP 366 responses will be different from the order of transmitted HTTP 367 requests. Also, the loss of an HTTP response will affect the order 368 of HTTP responses from the server. Our experience with the FreeBSD 369 SCTP implementation revealed that HTTP requests and responses can be 370 received out-of-order even under no loss conditions [N2008]. 371 Therefore, web client implementations MUST be aware that within an 372 SCTP assocation, the order of pipelined responses from the server may 373 not match the order of transmitted HTTP reqeusts. However, in case 374 of intra-stream pipelining, the order of HTTP responses within an 375 inbound SCTP stream *a* MUST match the order of transmitted HTTP 376 requests within the corresponding outbound SCTP stream *a*. 377 Consequently, within each SCTP stream, a web server MUST send its 378 responses to those reqeusts in the same order that the requests were 379 received. 381 5.3. Benefits for Progressive Images 383 Progressive images (e.g., JPEG, PNG) are coded such that the initial 384 bytes approximate the entire image, and successive bytes gradually 385 improve the image's quality/resolution. Simple experiments have 386 shown that user-perceived response time improvements for HTTP 1.1 387 (persistent and pipelined) transfers consisting of progressive images 388 are more significant than for similar transfers consisting of non- 389 progressive images. When each progressive image is downloaded on a 390 different SCTP stream, the Firefox implementation over FreeBSD SCTP 391 renders a good quality version of each progressive image 392 significantly earlier than the page download time [NAS2008]. These 393 page downloads were captured as movies and can be viewed at [Movies]. 395 6. Open Issues 397 This section discusses some of the open issues that require further 398 discussion and/or investigation. 400 6.1. How does a Web client decide between TCP vs. SCTP? 402 We see two options for how the web client can decide between using 403 TCP vs. SCTP for an HTTP (1.0 or 1.1) transfer. Option 1: The web 404 client tries in tandem to establish both a TCP connection and an SCTP 405 association to the server. The web client chooses TCP vs. SCTP 406 depending on which transport connection gets established first. 407 Option 2: The web client selects TCP vs. SCTP based on the URI. URIs 408 starting with "http://" or "https://" imply TCP and a new URI scheme 409 could be established for similar services over SCTP, such as, 410 "httpsctp://" or "httpssctp://". At this point, the authors believe 411 that option 1 is more desireable than option 2, and will have less 412 repercussions than option 2. 414 Web client implementations MUST be aware that an end user or the 415 other end-point (server/proxy) MAY choose to override the client's 416 default choice of transport (TCP vs. SCTP). Also, web clients SHOULD 417 cache information on which servers support SCTP, for later re-use. 419 6.2. TCP-SCTP Gateway 421 Research has shown that SCTP streams enable perceivable improvements 422 to web response times, especially in high latency and/or lossy last 423 hops such as VSAT links [N2008]. A TCP-SCTP gateway allows web 424 clients in such last hops to experiance the benefits of SCTP streams 425 even if the web server runs over TCP. Additionally, the gateway also 426 ensures that, web clients connecting to the Internet via the gateway 427 MAY always assume SCTP as the default transport instead of trying to 428 choose between TCP vs. SCTP as discussed in Section 6.1. 430 6.3. SCTP and NATs 432 The end-to-end path between a client and server MAY consist of one or 433 more Network Address Translators (NATs) that manipulate address and 434 port information in IP and SCTP headers. SCTP's association 435 establishment and multihoming mechanisms pose unique challenges in 436 the context of NATs. These issues are discussed in 437 [I-D.stewart-behave-sctpnat]. 439 7. Acknowledgments 441 8. References 442 8.1. Normative References 444 [I-D.ietf-tsvwg-sctpsocket] 445 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 446 Lei, "Sockets API Extensions for Stream Control 447 Transmission Protocol (SCTP)", 448 draft-ietf-tsvwg-sctpsocket-17 (work in progress), 449 July 2008. 451 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 452 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 454 [RFC2116] Apple, C. and K. Rossen, "X.500 Implementations 455 Catalog-96", RFC 2116, April 1997. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 461 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 462 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 464 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 465 RFC 4960, September 2007. 467 8.2. Informative References 469 [FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME_WAIT state in 470 TCP and its effect on busy servers", INFOCOM '99: 471 Proceedings of the IEEE INFOCOM Conference, pp. 1573- 472 1583 , 1999. 474 [I-D.stewart-behave-sctpnat] 475 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 476 Transmission Protocol (SCTP) Network Address Translation", 477 draft-stewart-behave-sctpnat-04 (work in progress), 478 July 2008. 480 [I-D.stewart-tsvwg-sctpstrrst] 481 Stewart, R., Lei, P., and M. Tuexen, "Stream Control 482 Transmission Protocol (SCTP) Stream Reset", 483 draft-stewart-tsvwg-sctpstrrst-00 (work in progress), 484 June 2008. 486 [Movies] "Movies Comparing HTTP over TCP vs. HTTP over SCTP 487 Streams", 2008, . 490 [N2008] Natarajan, P., "Leveraging Innovative Transport Layer 491 Services for Improved Application Performance", PhD 492 Dissertation, in progress, Computer & Information Sciences 493 Department, University of Delaware, USA , 2008. 495 [NAS2008] Natarajan, P., Amer, P., and R. Stewart, "Multistreamed 496 Web Transport for Developing Regions", NSDR '08: 497 Proceedings of the second ACM SIGCOMM workshop on 498 Networked systems for developing regions, Seattle, WA, 499 USA , 2008. 501 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 502 RFC 793, September 1981. 504 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 505 Conrad, "Stream Control Transmission Protocol (SCTP) 506 Partial Reliability Extension", RFC 3758, May 2004. 508 Authors' Addresses 510 Preethi Natarajan 511 University of Delaware 512 Computer and Information Sciences Department 513 Newark, DE 19716 514 USA 516 Phone: 517 Email: nataraja@cis.udel.edu 519 Paul D. Amer 520 University of Delaware 521 Computer and Information Sciences Department 522 Newark, DE 19716 523 USA 525 Phone: 302-831-1944 526 Email: amer@cis.udel.edu 527 Jonathan Leighton 528 University of Delaware 529 Computer and Information Sciences Department 530 Newark, DE 19716 531 USA 533 Phone: 534 Email: leighton@cis.udel.edu 536 Fred Baker 537 Cisco Systems 538 1121 Via Del Rey 539 Santa Barbara, CA 93117 540 USA 542 Phone: 543 Email: fred@cisco.com 545 Full Copyright Statement 547 Copyright (C) The IETF Trust (2008). 549 This document is subject to the rights, licenses and restrictions 550 contained in BCP 78, and except as set forth therein, the authors 551 retain all their rights. 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Intellectual Property 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org.