idnits 2.17.1 draft-natarajan-http-over-sctp-01.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 ([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 and authors Copyright Line does not match the current year -- The document date (March 9, 2009) is 5527 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-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 (-08) exists of draft-wood-tae-specifying-uri-transports-04 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 10 errors (**), 0 flaws (~~), 4 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: September 10, 2009 J. Leighton 6 University of Delaware 7 F. Baker 8 Cisco Systems 9 March 9, 2009 11 Using SCTP as a Transport Layer Protocol for HTTP 12 draft-natarajan-http-over-sctp-01.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 September 10, 2009. 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) [RFC2116] 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 other innovative services 56 unavailable in TCP. The objectives of this draft are three-fold: (i) 57 to highlight SCTP services that better match HTTP's needs than TCP, 58 (ii) to propose a design for persistent and pipelined HTTP 1.1 59 transactions over SCTP's multistreaming service, and (iii) to share 60 some lessons learned from implementing HTTP over SCTP. Finally, open 61 issues warranting more discussion and/or investigation are listed. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. SCTP Services for HTTP-based Applications . . . . . . . . . . 3 68 4. Designing HTTP over SCTP Streams . . . . . . . . . . . . . . . 5 69 4.1. Number of SCTP Streams . . . . . . . . . . . . . . . . . . 7 70 4.2. Mapping HTTP Transactions to SCTP Streams . . . . . . . . 7 71 5. Lessons Learned from Implementing HTTP over SCTP . . . . . . . 8 72 5.1. Avoiding Dependencies in Message Transmission . . . . . . 8 73 5.2. Order of Pipelined Requests and Responses . . . . . . . . 8 74 5.3. Benefits for Progressive Images . . . . . . . . . . . . . 9 75 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. How does a Web client decide between TCP vs. SCTP? . . . . 10 77 6.2. TCP-SCTP Gateway . . . . . . . . . . . . . . . . . . . . . 10 78 6.3. SCTP and NATs . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 SCTP was originally developed to carry telephony signaling messages 88 over IP networks. With continued work, SCTP evolved into a general 89 purpose transport protocol. Similar to TCP, SCTP offers a reliable, 90 full-duplex, congestion and flow-controlled transport connection. 91 Unlike TCP, SCTP offers other innovative services including 92 multistreaming, multihoming, partial-realiability, and message- 93 oriented data transfer. This document highlights some of the SCTP 94 services that are better suited to HTTP's needs than TCP services. 96 SCTP's multistreaming service is perhaps the most beneficial SCTP 97 service for HTTP. SCTP streams are logically separate data streams 98 within an SCTP "association" (analogous to a TCP connection). 99 Independent HTTP transactions, when transmitted over different SCTP 100 streams, can be delivered to the application without inter- 101 transaction head-of-line (HOL) blocking. Emulation results show that 102 SCTP streams eliminate HOL blocking and significantly improve web 103 response times [N2008]. This document presents our design for 104 persistent and pipelined HTTP 1.1 transactions over SCTP streams, and 105 some of the lessons learned from implementing this design in the 106 Apache server and Firefox browser. 108 Finally, this document lists some of the open issues that require 109 further discussion and/or investigation within the httpbis community. 111 2. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. SCTP Services for HTTP-based Applications 119 Similar to TCP, SCTP provides a reliable and in-order data transfer 120 service to HTTP. Additionally, SCTP provides other services 121 unavailable in TCP. These services are summarized below. The HTTP 122 over SCTP design proposed in Section 4 utilizes only a subset of 123 these SCTP services. The authors believe that other SCTP services 124 listed below MAY help HTTP, but the details remain unclear at this 125 time. 127 1. SCTP Multistreaming Avoids Head-of-Line (HOL) Blocking. 129 An SCTP stream is a unidirectional data flow within an SCTP 130 association. Each SCTP stream has its own sequencing space; data 131 arriving in-order within a stream is delivered to the application 132 without regard to the relative order of data arriving on other 133 streams. When independent HTTP transactions are transmitted over 134 different SCTP streams, these transactions are delivered to the 135 application without inter-transactoin HOL blocking. Section 4 136 discusses the benefits of HTTP over SCTP streams in more detail. 138 2. Four-way Handshake during Association Establishment. 140 To protect an end host from SYN-flooding DoS attacks, SCTP's 141 association establishment involves a four-way handshake with a 142 cookie mechanism. Since data transfer can begin in the third 143 leg, the four-way handshake does not delay data transmission any 144 further than TCP's three-way handshake for connection 145 establishment. 147 3. No Maximum Segment Lifetime (MSL) during Association Termination. 149 SCTP's association termination does not involve a TIME_WAIT state 150 [RFC0793], since the Initiation and Verification tags help to 151 associate SCTP Protocol Data Units (PDUs) with the corresponding 152 SCTP associations [RFC4960]. Note that TCP's TIME_WAIT state 153 increases memory and processing overload at a busy web server 154 [FTY1999]. 156 4. SCTP Multihoming for Improved Fault Tolerance. 158 Unlike TCP and UDP, an SCTP association can bind multiple IP 159 addresses at each peer. While an SCTP sender transmits data to a 160 single primary destination IP address, the sender concurrently 161 tracks the reachability of other destination addresses for fault- 162 tolerance purposes. If the primary address becomes unreachable, 163 an SCTP sender seamlessly migrates data transmission to an 164 alternate active destination address. Multihomed clients and/or 165 web servers will automatically benefit from greater fault- 166 tolreance by using SCTP. 168 5. Preserving Application Message Boundaries. 170 Similar to UDP, SCTP offers message-oriented data transfer. SCTP 171 preserves application message boundaries; messages are delivered 172 in their entirety to the receiving application. Applications 173 using SCTP do not require explicit message delimiters, which 174 simplifies message parsing. However, the advantages of SCTP's 175 message-oriented data transmission service to HTTP is unclear, 176 and the proposed HTTP over SCTP design in Section 4 does not 177 exploit this SCTP service. To preserve message boundaries, SCTP 178 employs a fragmentation and reassemebly algorithm. This 179 algorithm creates dependencies in message transmission, discussed 180 further in Section 5.1, [N2008]. 182 6. Partial Reliability. 184 Reference [RFC3758] describes PR-SCTP, an extenstion to 185 [RFC4960], that enables partially reliable data transfer between 186 a PR-SCTP sender and receiver. In TCP and plain SCTP, all 187 transmitted data are guaranteed to be delivered. Alternatively, 188 PR-SCTP gives an application the flexibility to notify how 189 persistent the transport sender should be in trying to 190 communicate a particular message to the receiver. An application 191 MAY specify a "lifetime" for each message. A PR-SCTP sender 192 tries to transmit the message during this lifetime. Upon 193 lifetime expiration, a PR-SCTP sender discards the message 194 irrespective of whether or not the message was successfully 195 transmitted and/or acknowledged. This timed reliability in data 196 transfer may be useful in applications that regularly generate 197 new data that obsoletes earlier data, for example, online gaming 198 application in which a player frequently generates new position 199 coordinates or other data with ephemeral significance. The 200 proposed HTTP over SCTP design in Section 4 currently does not 201 make use of this PR-SCTP service. 203 7. Unordered Data Delivery. 205 Similar to UDP and unlike TCP, SCTP offers unordered data 206 delivery service. An application message, marked for unordered 207 delivery, is delivered to the receiving application as soon as 208 the message arrives at the SCTP receiver. Unlike UDP, SCTP 209 provides reliability for unordered data. Note that a single SCTP 210 association can transfer both ordered and unordered messages. 211 The proposed HTTP over SCTP design in Section 4 does not make use 212 of this SCTP service. 214 4. Designing HTTP over SCTP Streams 216 In this document, an HTTP GET request (or response) is considered 217 independent when its application-level processing does not depend on 218 the availability of other HTTP GET requests (or responses). The 219 primary objective of our design is to exploit SCTP's multistreaming 220 service to avoid HOL blocking between independent HTTP transactions. 222 Note that HTTP transctions do not experience HOL blocking when either 223 (i) each HTTP transaction is transmitted over a different TCP 224 connection (HTTP 1.0) [RFC1945], or (ii) multiple HTTP transactions 225 are transmitted in a non-pipelined fashion over a single persistent 226 TCP connection [RFC2616]. Consequently, we do not expect SCTP's 227 multistreaming to improve response times for an HTTP 1.0 transfer or 228 a non-pipelined HTTP 1.1 transfer. Nonetheless, these HTTP transfers 229 may benefit from other SCTP features such as multihoming, four-way 230 association establishment handshake etc., mentioned in Section 3. 231 Note that a client or server implementing HTTP 1.0 or non-pipelined 232 HTTP 1.1 over TCP can be trivially mapped to work over SCTP by 233 creating an SCTP socket instead of a TCP socket 234 [I-D.ietf-tsvwg-sctpsocket]. 236 An HTTP transaction may be HOL blocked by another independent HTTP 237 transaction only when these transactions are transmitted in a 238 pipelined fashion over a single TCP connection. Transferring these 239 transactions over different streams of a single SCTP association 240 elimiates the inter-transaction HOL blocking. Emulation results show 241 that persistent and pipelined HTTP 1.1 transfers over a single 242 multistreamed SCTP association experience better response times when 243 compared to similar transfers over a single TCP connection. The 244 difference in TCP vs. SCTP response times increases and is more 245 visually perceivable in high latency and lossy browsing conditions, 246 such as those found in the developing world [NAS2008]. 248 Apart from improving response times, SCTP streams may also reduce 249 setup and memory costs at a web server/cache/proxy. To reduce HOL 250 blocking, web clients open muliple TCP connections to download 251 independent HTTP transactions from the same server. In contrast, a 252 web client using SCTP eliminates HOL blocking by simply increasing 253 the number of streams within a single SCTP association. Each TCP 254 connection or SCTP stream incurs additional setup and memory overhead 255 at both the client and server. However, the costs associated with a 256 new SCTP stream are in general lower than those associated with a new 257 TCP connection, and the cost gains from using SCTP increase as the 258 number of web clients increase. The exact difference in TCP vs. SCTP 259 resource requirements depends on the respective protocol 260 implementations [N2008]. 262 Two guidelines govern the HTTP over SCTP streams design discussed 263 below: (i) make no changes to the existing HTTP specification (such 264 as the URI syntax), to reduce deployment issues, and (ii) minimize 265 SCTP-related state information at the server so that SCTP 266 multistreaming does not further contribute to the server being a 267 performance bottleneck. Detailed discussions on various design 268 decisions can be found in [N2008]. The two components of this design 269 are discussed next. 271 4.1. Number of SCTP Streams 273 SCTP streams are uni-directional; inbound and outbound streams carry 274 data to and from each end point, respectively. Each inbound or 275 outbound stream incurs additional memory overhead in the SCTP 276 Protocol Control Block, and this overhead depends on the SCTP 277 implementation. The number of inbound or outbound SCTP streams is 278 negotiated during the association establishment phase (Figure 1). 279 Before association establishment, the number of inbound or outbound 280 streams may be modified by using appropriate SCTP socket options 281 [I-D.ietf-tsvwg-sctpsocket]. The stream "reset" functionality allows 282 for re-negotiating the number of streams after association 283 establishment [I-D.stewart-tsvwg-sctpstrrst]. When using SCTP for 284 HTTP, an SCTP association MAY employ any number of inbound or 285 outbound streams (up to 65,536 [RFC4960]). However, for every 286 outbound SCTP stream with id *a* on which the client transmits 287 requests, there MUST be a corresponding inbound stream with id *a*. 288 Typically, this is achieved by opening an SCTP association with equal 289 number of inbound and outbound streams. 291 Client Server 292 | | 293 |-----------INIT (IS=m,OS=m)------------->| 294 #Streams = MIN (m,n) |<---------INIT-ACK (IS=n,OS=n)-----------| #Streams = MIN (m,n) 295 | | 296 / . / 297 \ . \ 298 | | 299 |----------HTTP GET i (on OS a)---------->| 300 |<---------HTTP RES i (on OS a)-----------| 301 | | 302 IS: Inbound Stream 303 OS: Outbound Stream 305 Figure 1: HTTP over SCTP Streams 307 4.2. Mapping HTTP Transactions to SCTP Streams 309 To avoid incurring additional processing overhead at the web server, 310 a web client determines the SCTP stream number on which each HTTP 311 transaction is transmitted. In the example shown in Figure 1, the 312 web client maps HTTP transaction *i* to SCTP stream *a*. The client 313 transmits HTTP request *i* on the client's outbound (server's 314 inbound) SCTP stream *a*. The web server transmits the corresponding 315 response on the server's outbound (client's inbound) SCTP stream *a*. 317 The sctp_sendmsg and sctp_recvmsg APIs, respectively, can be used to 318 transmit data on a particular SCTP outbound stream, and determine the 319 SCTP inbound stream number on which an application message was 320 received. 322 When the number of available SCTP streams is greater than or equal to 323 the number of HTTP transactions, a web client SHOULD NOT pipeline 324 transactions intra-stream, i.e., each HTTP transaction SHOULD be 325 mapped to a different SCTP stream. When the number of available SCTP 326 streams is less than the number of HTTP transactions, the web client 327 MAY employ a scheduling policy to pipeline transactions intra-stream. 328 Our implementation employs a round-robin scheduling policy, where 329 HTTP transactions are mapped to available SCTP streams in a round- 330 robin fashion. Other scheduling policies MAY be considered. For 331 example, in a lossy network environment, such as wide area wireless 332 connectivity through GPRS, a better scheduling policy might be 333 'smallest pending object first' where the next GET request goes on 334 the SCTP stream that has the smallest sum of object sizes pending 335 transfer. Such a policy reduces the probability of intra-stream HOL 336 blocking, i.e., HOL blocking between responses downloaded on the same 337 SCTP stream. 339 5. Lessons Learned from Implementing HTTP over SCTP 341 HTTP over SCTP was implemented in the Apache server and Firefox 342 browser at the University of Delaware's Protocol Engineering Lab. 343 Some lessons learned during this experience are discussed below. 344 More details can be found in [N2008]. 346 5.1. Avoiding Dependencies in Message Transmission 348 SCTP's fragmentation and reassembly algorithm creates dependencies in 349 message transmission, i.e., a fragment of message i+1 cannot be 350 transmitted until all fragments of message i have been transmitted. 351 If messages i and i+1 are of sizes 100KB and 1KB respectively, the 352 100KB message transmission can unnecessarily block transmission of 353 the 1KB message. The client or server application can overcome this 354 by splitting each HTTP request or response into multiple messages, 355 such that, each message at the SCTP layer results in a PMTU-sized 356 SCTP PDU, and is not fragmented further by SCTP. An application can 357 use either the SCTP_PEER_ADDR or the SCTP_STATUS socket options to 358 obtain an SCTP association's PMTU [I-D.ietf-tsvwg-sctpsocket]. 360 5.2. Order of Pipelined Requests and Responses 362 Section 8 of [RFC2616] mandates that in HTTP 1.1 with pipelining, "a 363 server MUST send its responses to those requests in the same order 364 that the requests were received." Since TCP always delivers data in- 365 order, the order of HTTP requests received by the server, and 366 therefore, the order of HTTP responses generated by the server match 367 the order of transmitted HTTP requests from the client. 368 Consequently, a web client can assume that, within a TCP connection, 369 the order of HTTP responses from the server always matches the order 370 of transmitted HTTP requests. Unlike TCP, SCTP's multistreaming 371 feature delivers out-of-order data at both the server and client. 372 When HTTP requests from client to server are lost, requests 373 transmitted over different SCTP streams will be delivered out-of- 374 order at the server, and therefore, the order of generated HTTP 375 responses will be different from the order of transmitted HTTP 376 requests. Also, the loss of an HTTP response will affect the order 377 of HTTP responses from the server. Our experience with the FreeBSD 378 SCTP implementation revealed that HTTP requests and responses can be 379 received out-of-order even under no loss conditions [N2008]. 380 Therefore, web client implementations MUST be aware that within an 381 SCTP assocation, the order of pipelined responses from the server may 382 not match the order of transmitted HTTP reqeusts. However, in case 383 of intra-stream pipelining, the order of HTTP responses within an 384 inbound SCTP stream *a* MUST match the order of transmitted HTTP 385 requests within the corresponding outbound SCTP stream *a*. 386 Consequently, within each SCTP stream, a web server MUST send its 387 responses to those reqeusts in the same order that the requests were 388 received. 390 5.3. Benefits for Progressive Images 392 Progressive images (e.g., JPEG, PNG) are coded such that the initial 393 bytes approximate the entire image, and successive bytes gradually 394 improve the image's quality/resolution. Simple experiments have 395 shown that user-perceived response time improvements for HTTP 1.1 396 (persistent and pipelined) transfers consisting of progressive images 397 are more significant than for similar transfers consisting of non- 398 progressive images. When each progressive image is downloaded on a 399 different SCTP stream, the Firefox implementation over FreeBSD SCTP 400 renders a good quality version of each progressive image 401 significantly earlier than the page download time [NAS2008]. These 402 page downloads were captured as movies and can be viewed at [Movies]. 404 6. Open Issues 406 This section discusses some of the open issues that require further 407 discussion and/or investigation. 409 6.1. How does a Web client decide between TCP vs. SCTP? 411 We see three options for how the web client can decide between TCP 412 vs. SCTP for an HTTP (1.0 or 1.1) transfer. Option 1: The web client 413 tries in tandem to establish both a TCP connection and an SCTP 414 association to the server. The web client chooses TCP vs. SCTP 415 depending on which transport connection gets established first. 416 Option 2: [RFC3263] describes how SIP proxies and clients can select 417 the transport protocol using SRV records [RFC2782]. A similar 418 solution can be conceived for HTTP. Option 3: The web client selects 419 TCP vs. SCTP based on the URI. URIs starting with "http://" or 420 "https://" imply TCP and a new URI scheme could be established for 421 similar services over SCTP, such as, "http-sctp://" or 422 "https-sctp://" [I-D.wood-tae-specifying-uri-transports]. While 423 option 1 is simplistic, the other options require support from new 424 mechanisms and/or protocols. 426 Web client implementations MUST be aware that an end user or the 427 other end-point (server/proxy) MAY choose to override the client's 428 default choice of transport (TCP vs. SCTP). Also, web clients SHOULD 429 cache information on which servers support SCTP, for later re-use. 431 6.2. TCP-SCTP Gateway 433 Research has shown that SCTP streams enable perceivable improvements 434 to web response times, especially in high latency and/or lossy last 435 hops such as VSAT links [N2008]. A TCP-SCTP gateway allows web 436 clients in such last hops to experiance the benefits of SCTP streams 437 even if the web server runs over TCP. Additionally, the gateway also 438 ensures that, web clients connecting to the Internet via the gateway 439 MAY always assume SCTP as the default transport instead of trying to 440 choose between TCP vs. SCTP as discussed in Section 6.1. 442 6.3. SCTP and NATs 444 The end-to-end path between a client and server MAY consist of one or 445 more Network Address Translators (NATs) that manipulate address and 446 port information in IP and SCTP headers. SCTP's association 447 establishment and multihoming mechanisms pose unique challenges in 448 the context of NATs. These issues are discussed in 449 [I-D.ietf-behave-sctpnat]. 451 7. Acknowledgments 453 8. References 454 8.1. Normative References 456 [I-D.ietf-tsvwg-sctpsocket] 457 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 458 Lei, "Sockets API Extensions for Stream Control 459 Transmission Protocol (SCTP)", 460 draft-ietf-tsvwg-sctpsocket-19 (work in progress), 461 February 2009. 463 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 464 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 466 [RFC2116] Apple, C. and K. Rossen, "X.500 Implementations 467 Catalog-96", RFC 2116, April 1997. 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 473 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 474 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 476 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 477 RFC 4960, September 2007. 479 8.2. Informative References 481 [FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME_WAIT state in 482 TCP and its effect on busy servers", INFOCOM '99: 483 Proceedings of the IEEE INFOCOM Conference, pp. 1573- 484 1583 , 1999. 486 [I-D.ietf-behave-sctpnat] 487 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 488 Transmission Protocol (SCTP) Network Address Translation", 489 draft-ietf-behave-sctpnat-01 (work in progress), 490 February 2009. 492 [I-D.stewart-tsvwg-sctpstrrst] 493 Stewart, R., Lei, P., and M. Tuexen, "Stream Control 494 Transmission Protocol (SCTP) Stream Reconfiguration", 495 draft-stewart-tsvwg-sctpstrrst-01 (work in progress), 496 February 2009. 498 [I-D.wood-tae-specifying-uri-transports] 499 Wood, L., "Specifying transport mechanisms for retrieval 500 or delivery of URIs", 501 draft-wood-tae-specifying-uri-transports-04 (work in 502 progress), February 2009. 504 [Movies] "Movies Comparing HTTP over TCP vs. HTTP over SCTP 505 Streams", 2008, . 508 [N2008] Natarajan, P., "Leveraging Innovative Transport Layer 509 Services for Improved Application Performance", PhD 510 Dissertation, Computer & Information Sciences Department, 511 University of Delaware, USA , 2009. 513 [NAS2008] Natarajan, P., Amer, P., and R. Stewart, "Multistreamed 514 Web Transport for Developing Regions", NSDR '08: 515 Proceedings of the second ACM SIGCOMM workshop on 516 Networked systems for developing regions, Seattle, WA, 517 USA , 2008. 519 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 520 RFC 793, September 1981. 522 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 523 specifying the location of services (DNS SRV)", RFC 2782, 524 February 2000. 526 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 527 Protocol (SIP): Locating SIP Servers", RFC 3263, 528 June 2002. 530 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 531 Conrad, "Stream Control Transmission Protocol (SCTP) 532 Partial Reliability Extension", RFC 3758, May 2004. 534 Authors' Addresses 536 Preethi Natarajan 537 Cisco Systems 538 170 West Tasman Drive 539 San Jose, CA 95134 540 USA 542 Phone: 543 Email: prenatar@cisco.com 544 Paul D. Amer 545 University of Delaware 546 Computer and Information Sciences Department 547 Newark, DE 19716 548 USA 550 Phone: 302-831-1944 551 Email: amer@cis.udel.edu 553 Jonathan Leighton 554 University of Delaware 555 Computer and Information Sciences Department 556 Newark, DE 19716 557 USA 559 Phone: 560 Email: leighton@cis.udel.edu 562 Fred Baker 563 Cisco Systems 564 1121 Via Del Rey 565 Santa Barbara, CA 93117 566 USA 568 Phone: 569 Email: fred@cisco.com