One document matched: draft-natarajan-httpbis-sctp-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>  <!-- but keep a blank line between list items -->
<?rfc sortrefs="yes" ?>   <!-- sort referneces -->

<rfc category="std" ipr="full3978" docName="draft-natarajan-httpbis-sctp-00.txt">
<front>
<title abbrev="SCTP for HTTP">
Using SCTP as a Transport Layer Protocol for HTTP
</title>

<!-- ************** Preethi Natarajan***************-->
<author initials="P. N." surname="Natarajan" fullname="Preethi Natarajan">
<organization>University of Delaware</organization>
<address>
<postal>
 <street>Computer and Information Sciences Department</street>
 <city>Newark</city> <region>DE</region>
 <code>19716</code>
 <country>USA</country>
</postal>
<phone></phone>
<email>nataraja@cis.udel.edu</email>
</address>
</author>

<!--Paul D. Amer-->
<author initials="P. D. A." surname="Amer" fullname="Paul D. Amer">
<organization>University of Delaware</organization>
<address>
<postal>
 <street>Computer and Information Sciences Department</street>
 <city>Newark</city> <region>DE</region>
 <code>19716</code>
 <country>USA</country>
</postal>
<phone>302-831-1944</phone>
<email>amer@cis.udel.edu</email>
</address>
</author>

<!--Jon Leighton-->
<author initials="J. T. L." surname="Leighton" fullname="Jonathan Leighton">
<organization>University of Delaware</organization>
<address>
<postal>
 <street>Computer and Information Sciences Department</street>
 <city>Newark</city> <region>DE</region>
 <code>19716</code>
 <country>USA</country>
</postal>
<phone></phone>
<email>leighton@cis.udel.edu</email>
</address>
</author>

<!--Jon Leighton-->
<author initials="F.B." surname="Baker" fullname="Fred Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
 <street>1121 Via Del Rey</street>
 <city>Santa Barbara</city> <region>CA</region>
 <code>93117</code>
 <country>USA</country>
</postal>
<phone></phone>
<email>fred@cisco.com</email>
</address>
</author>

<!---- Finalize other authors ----->

<date year="2008" />

<keyword>Internet-Draft</keyword>

<!-- ************** ABSTRACT *************** -->

<abstract>
<t>
Hyper-Text Transfer Protocol (HTTP) <xref target="RFC2116" /> requires a reliable transport for end-to-end communication. While historically TCP has been used for this purpose, this document proposes an alternative -- the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960" />. Similar to TCP, SCTP offers a reliable end-to-end transport connection to applications. Additionally, SCTP offers other innovative services unavailable in TCP. The objectives of this draft are three-fold: (i) to highlight SCTP services that better match HTTP's needs than TCP, (ii) to propose a design for persistent and pipelined HTTP 1.1 transactions over SCTP's multistreaming service, and (iii) to share some lessons learned from implementing HTTP over SCTP.  Finally, open issues warranting more discussion and/or investigation are listed. 

</t>
</abstract>
</front>

<middle>
<!-- ************** INTRODUCTION *************** -->
<section anchor="introduction" title="Introduction">
<t>
SCTP was originally developed to carry telephony signaling messages over IP networks. With continued work, SCTP evolved into a general purpose transport protocol. Similar to TCP, SCTP offers a reliable, full-duplex, congestion and flow-controlled transport connection. Unlike TCP, SCTP offers other innovative services including multistreaming, multihoming, partial-realiability, and message-oriented data transfer. This document highlights some of the SCTP services that are better suited to HTTP's needs than TCP services.
</t>

<t>
SCTP's multistreaming service is perhaps the most beneficial SCTP service for HTTP. SCTP streams are logically separate data streams within an SCTP "association" (analogous to a TCP connection). Independent HTTP transactions, when transmitted over different SCTP streams, can be delivered to the application without inter-transaction head-of-line (HOL) blocking. Emulation results show that SCTP streams eliminate HOL blocking and significantly improve web response times <xref target="N2008" />. This document presents our design for persistent and pipelined HTTP 1.1 transactions over SCTP streams, and some of the lessons learned from implementing this design in the Apache server and Firefox browser.  
</t>

<t>
Finally, this document lists some of the open issues that require further discussion and/or investigation within the httpbis community. 
</t>

</section>



<!-- ************** CONVENTIONS *************** -->
<section anchor="conventions" title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section> <!-- conventions -->

<section anchor="compare" title="SCTP Services for HTTP-based Applications">
<t>
Similar to TCP, SCTP provides a reliable and in-order data transfer service to HTTP. Additionally, SCTP provides other services unavailable in TCP. These services are summarized below. The HTTP over SCTP design proposed in <xref target="design"/> utilizes only a subset of these SCTP services. The authors believe that other SCTP services listed below MAY help HTTP, but the details remain unclear at this time. 
</t>
<vspace blankLines='1' />

<list style='numbers'>

<t>
SCTP Multistreaming Avoids Head-of-Line (HOL) Blocking.
<vspace blankLines='1' />
An SCTP stream is a unidirectional data flow within an SCTP association. Each SCTP stream has its own sequencing space; data arriving in-order within a stream is delivered to the application without regard to the relative order of data arriving on other streams. When independent HTTP transactions are transmitted over different SCTP streams, these transactions are delivered to the application without inter-transactoin HOL blocking. <xref target="design"/> discusses the benefits of HTTP over SCTP streams in more detail.
 
</t>

<t>
Four-way Handshake during Association Establishment.
<vspace blankLines='1' />
To protect an end host from SYN-flooding DoS attacks, SCTP's association establishment involves a four-way handshake with a cookie mechanism. Since data transfer can begin in the third leg, the four-way handshake does not delay data transmission any further than TCP's three-way handshake for connection establishment.  
</t>

<t>
No Maximum Segment Lifetime (MSL) during Association Termination.
<vspace blankLines='1' />
SCTP's association termination does not involve a TIME_WAIT state <xref target="RFC0793" />, since the Initiation and Verification tags help to associate SCTP Protocol Data Units (PDUs) with the corresponding SCTP associations <xref target="RFC4960" />. Note that TCP's TIME_WAIT state increases memory and processing overload at a busy web server [FTY1999].
</t>

<t>
SCTP Multihoming for Improved Fault Tolerance.
<vspace blankLines='1' />
Unlike TCP and UDP, an SCTP association can bind multiple IP addresses at each peer. While an SCTP sender transmits data to a single primary destination IP address, the sender concurrently tracks the reachability of other destination addresses for fault-tolerance purposes. If the primary address becomes unreachable, an SCTP sender seamlessly migrates data transmission to an alternate active destination address. Multihomed clients and/or web servers will automatically benefit from greater fault-tolreance by using SCTP.
</t>

<t>
Preserving Application Message Boundaries.
<vspace blankLines='1' />
Similar to UDP, SCTP offers message-oriented data transfer. SCTP preserves application message boundaries; messages are delivered in their entirety to the receiving application. Applications using SCTP do not require explicit message delimiters, which simplifies message parsing. However, the advantages of SCTP's message-oriented data transmission service to HTTP is unclear, and the proposed HTTP over SCTP design in <xref target="design"/> does not exploit this SCTP service.  To preserve message boundaries, SCTP employs a fragmentation and reassemebly algorithm. This algorithm creates dependencies in message transmission, discussed further in <xref target="message" />, <xref target="N2008"/>.
</t>

<t>
Partial Reliability.
<vspace blankLines='1' /> 
Reference <xref target="RFC3758" /> describes PR-SCTP, an extenstion to <xref target="RFC4960" />, that enables partially reliable data transfer between a PR-SCTP sender and receiver.  In TCP and plain SCTP, all transmitted data are guaranteed to be delivered. Alternatively, PR-SCTP gives an application the flexibility to notify how persistent the transport sender should be in trying to communicate a particular message to the receiver. An application MAY specify a "lifetime" for each message.  A PR-SCTP sender tries to transmit the message during this lifetime.  Upon lifetime expiration, a PR-SCTP sender discards the message irrespective of whether or not the message was successfully transmitted and/or acknowledged.  This timed reliability in data transfer may be useful in applications that regularly generate new data that obsoletes earlier data, for example, online gaming application in which a player frequently generates new position coordinates or other data with ephemeral significance. The proposed HTTP over SCTP design in <xref target="design"/> currently does not make use of this PR-SCTP service.
</t>

<t>
Unordered Data Delivery.
<vspace blankLines='1' />
Similar to UDP and unlike TCP, SCTP offers unordered data delivery service.  An application message, marked for unordered delivery, is delivered to the receiving application as soon as the message arrives at the SCTP receiver. Unlike UDP, SCTP provides reliability for unordered data.  Note that a single SCTP association can transfer both ordered and unordered messages.  The proposed HTTP over SCTP design in <xref target="design"/> does not make use of this SCTP service.
</t>

</list>
</section>

<section anchor="design" title="Designing HTTP over SCTP Streams">
<t>
In this document, an HTTP GET request (or response) is considered independent when its application-level processing does not depend on the availability of other HTTP GET requests (or responses). The primary objective of our design is to exploit SCTP's multistreaming service to avoid HOL blocking between independent HTTP transactions. 
</t>

<t>
Note that HTTP transctions do not experience HOL blocking when either (i) each HTTP transaction is transmitted over a different TCP connection (HTTP 1.0) <xref target="RFC1945"/>, or (ii) multiple HTTP transactions are transmitted in a non-pipelined fashion over a single persistent TCP connection <xref target="RFC2616"/>. Consequently, we do not expect SCTP's multistreaming to improve response times for an HTTP 1.0 transfer or a non-pipelined HTTP 1.1 transfer. Nonetheless, these HTTP transfers may benefit from other SCTP features such as multihoming, four-way association establishment handshake etc., mentioned in <xref target="compare"/>. Note that a client or server implementing HTTP 1.0 or non-pipelined HTTP 1.1 over TCP can be trivially mapped to work over SCTP by creating an SCTP socket instead of a TCP socket <xref target="I-D.ietf-tsvwg-sctpsocket" />.
</t>

<t>
An HTTP transaction may be HOL blocked by another independent HTTP transaction only when these transactions are transmitted in a pipelined fashion over a single TCP connection. Transferring these transactions over different streams of a single SCTP association elimiates the inter-transaction HOL blocking. Emulation results show that persistent and pipelined HTTP 1.1 transfers over a single multistreamed SCTP association experience better response times when compared to similar transfers over a single TCP connection.  The difference in TCP vs. SCTP response times increases and is more visually perceivable in high latency and lossy browsing conditions, such as those found in the developing world <xref target="NAS2008" />. 
</t>


<t>
Apart from improving response times, SCTP streams may also reduce setup and memory costs at a web server/cache/proxy. To reduce HOL blocking, web clients open muliple TCP connections to download independent HTTP transactions from the same server. In contrast, a web client using SCTP eliminates HOL blocking by simply increasing the number of streams within a single SCTP association. Each TCP connection or SCTP stream incurs additional setup and memory overhead at both the client and server. However, the costs associated with a new SCTP stream are in general lower than those associated with a new TCP connection, and the cost gains from using SCTP increase as the number of web clients increase. The exact difference in TCP vs. SCTP resource requirements depends on the respective protocol implementations <xref target="N2008" />.  
</t>

<t>
Two guidelines govern the HTTP over SCTP streams design discussed below: (i) make no changes to the existing HTTP specification (such as the URI syntax), to reduce deployment issues, and (ii) minimize SCTP-related state information at the server so that SCTP multistreaming does not further contribute to the server being a performance bottleneck. Detailed discussions on various design decisions can be found in <xref target="N2008" />. The two components of this design are discussed next.
</t>


<section title="Number of SCTP Streams">
<t>
SCTP streams are uni-directional; inbound and outbound streams carry data to and from each end point, respectively.  Each inbound or outbound stream incurs additional memory overhead in the SCTP Protocol Control Block, and this overhead depends on the SCTP implementation.  The number of inbound or outbound SCTP streams is negotiated during the association establishment phase (<xref target="1"/>).  Before association establishment, the number of inbound or outbound streams may be modified by using appropriate SCTP socket options <xref target="I-D.ietf-tsvwg-sctpsocket" />. The stream "reset" functionality allows for re-negotiating the number of streams after association establishment <xref target="I-D.stewart-tsvwg-sctpstrrst" />.  When using SCTP for HTTP, an SCTP association MAY employ any number of inbound or outbound streams (up to 65,536 <xref target="RFC4960"/>). However, for every outbound SCTP stream with id <spanx style="strong">a</spanx> on which the client transmits requests, there MUST be a corresponding inbound stream with id <spanx style="strong">a</spanx>. Typically, this is achieved by opening an SCTP association with equal number of inbound and outbound streams. 
</t>
</section>

<figure align = "center" title="HTTP over SCTP Streams" anchor="1">
<artwork>
<![CDATA[
                  Client                                    Server
                     |                                         |
                     |-----------INIT (IS=m,OS=m)------------->|
#Streams = MIN (m,n) |<---------INIT-ACK (IS=n,OS=n)-----------| #Streams = MIN (m,n)
                     |                                         |
                     /                   .                     /
                     \                   .                     \
                     |                                         |
                     |----------HTTP GET i (on OS a)---------->|
                     |<---------HTTP RES i (on OS a)-----------|
                     |                                         |
IS: Inbound Stream
OS: Outbound Stream
]]>

</artwork>
</figure>



<section title="Mapping HTTP Transactions to SCTP Streams"/>
<t>
To avoid incurring additional processing overhead at the web server, a web client determines the SCTP stream number on which each HTTP transaction is transmitted. In the example shown in <xref target="1"/>, the web client maps HTTP transaction <spanx style="strong">i</spanx> to SCTP stream <spanx style="strong">a</spanx>. The client transmits HTTP request <spanx style="strong">i</spanx> on the client's outbound (server's inbound) SCTP stream <spanx style="strong">a</spanx>. The web server transmits the corresponding response on the server's outbound (client's inbound) SCTP stream <spanx style="strong">a</spanx>. The sctp_sendmsg and sctp_recvmsg APIs, respectively, can be used to transmit data on a particular SCTP outbound stream, and determine the SCTP inbound stream number on which an application message was received.
</t>
<t>
When the number of available SCTP streams is greater than or equal to the number of HTTP transactions, a web client SHOULD NOT pipeline transactions intra-stream, i.e., each HTTP transaction SHOULD be mapped to a different SCTP stream. When the number of available SCTP streams is less than the number of HTTP transactions, the web client MAY employ a scheduling policy to pipeline transactions intra-stream. Our implementation employs a round-robin scheduling policy, where HTTP transactions are mapped to available SCTP streams in a round-robin fashion. Other scheduling policies MAY be considered. For example, in a lossy network environment, such as wide area wireless connectivity through GPRS, a better scheduling policy might be 'smallest pending object first' where the next GET request goes on the SCTP stream that has the smallest sum of object sizes pending transfer. Such a policy reduces the probability of intra-stream HOL blocking, i.e., HOL blocking between responses downloaded on the same SCTP stream.
</t>
</section>



<section anchor="lessons" title="Lessons Learned from Implementing HTTP over SCTP">
<t>
HTTP over SCTP was implemented in the Apache server and Firefox browser at the University of Delaware's Protocol Engineering Lab. Some lessons learned during this experience are discussed below. More details can be found in <xref target="N2008" />. 
</t>

<section anchor="message" title="Avoiding Dependencies in Message Transmission">
<t>
SCTP's fragmentation and reassembly algorithm creates dependencies in message transmission, i.e., a fragment of message i+1 cannot be transmitted until all fragments of message i have been transmitted. If messages i and i+1 are of sizes 100KB and 1KB respectively, the 100KB message transmission can unnecessarily block transmission of the 1KB message. The client or server application can overcome this by splitting each HTTP request or response into multiple messages, such that, each message at the SCTP layer results in a PMTU-sized SCTP PDU, and is not fragmented further by SCTP. An application can use either the SCTP_PEER_ADDR or the SCTP_STATUS socket options to obtain an SCTP association's PMTU <xref target="I-D.ietf-tsvwg-sctpsocket" />.
</t>
</section>

<section title="Order of Pipelined Requests and Responses">
<t>
Section 8 of <xref target="RFC2616" /> mandates that in HTTP 1.1 with pipelining, <spanx style="verb">a server MUST send its responses to those requests in the same order that the requests were received.</spanx> Since TCP always delivers data in-order, the order of HTTP requests received by the server, and therefore, the order of HTTP responses generated by the server match the order of transmitted HTTP requests from the client.  Consequently, a web client can assume that, within a TCP connection, the order of HTTP responses from the server always matches the order of transmitted HTTP requests. Unlike TCP, SCTP's multistreaming feature delivers out-of-order data at both the server and client. When HTTP requests from client to server are lost, requests transmitted over different SCTP streams will be delivered out-of-order at the server, and therefore, the order of generated HTTP responses will be different from the order of transmitted HTTP requests. Also, the loss of an HTTP response will affect the order of HTTP responses from the server. Our experience with the FreeBSD SCTP implementation revealed that HTTP requests and responses can be received out-of-order even under no loss conditions <xref target="N2008" />. Therefore, web client implementations MUST be aware that within an SCTP assocation, the order of pipelined responses from the server may not match the order of transmitted HTTP reqeusts. However, in case of intra-stream pipelining, the order of HTTP responses within an inbound SCTP stream <spanx style="strong">a</spanx> MUST match the order of transmitted HTTP requests within the corresponding outbound SCTP stream <spanx style="strong">a</spanx>. Consequently, within each SCTP stream, a web server MUST send its responses to those reqeusts in the same order that the requests were received.  
</t>
</section>

<section title="Benefits for Progressive Images">
<t>
Progressive images (e.g., JPEG, PNG) are coded such that the initial bytes approximate the entire image, and successive bytes gradually improve the image's quality/resolution. Simple experiments have shown that user-perceived response time improvements for HTTP 1.1 (persistent and pipelined) transfers consisting of progressive images are more significant than for similar transfers consisting of non-progressive images. When each progressive image is downloaded on a different SCTP stream, the Firefox implementation over FreeBSD SCTP renders a good quality version of each progressive image significantly earlier than the page download time <xref target="NAS2008" />. These page downloads were captured as movies and can be viewed at <xref target="Movies" />.  
</t>
</section>

</section>
<section anchor="open issues" title="Open Issues">
<t>
This section discusses some of the open issues that require further discussion and/or investigation. 
</t>

<section anchor="choose" title="How does a Web client decide between TCP vs. SCTP?">
<t>
We see two options for how the web client can decide between using TCP vs. SCTP for an HTTP (1.0 or 1.1) transfer. 
Option 1: The web client tries in tandem to establish both a TCP connection and an SCTP association to the server. The web client chooses TCP vs. SCTP depending on which transport connection gets established first. 
Option 2: The web client selects TCP vs. SCTP based on the URI. URIs starting with "http://" or "https://" imply TCP and a new URI scheme could be established for similar services over SCTP, such as, "httpsctp://" or "httpssctp://". 
At this point, the authors believe that option 1 is more desireable than option 2, and will have less repercussions than option 2. 
</t>

<t>
Web client implementations MUST be aware that an end user or the other end-point (server/proxy) MAY choose to override the client's default choice of transport (TCP vs. SCTP). Also, web clients SHOULD cache information on which servers support SCTP, for later re-use.
</t>
</section>

<section title="TCP-SCTP Gateway">
<t>
Research has shown that SCTP streams enable perceivable improvements to web response times, especially in high latency and/or lossy last hops such as VSAT links <xref target="N2008" />. A TCP-SCTP gateway allows web clients in such last hops to experiance the benefits of SCTP streams even if the web server runs over TCP.  Additionally, the gateway also ensures that, web clients connecting to the Internet via the gateway MAY always assume SCTP as the default transport instead of trying to choose between TCP vs. SCTP as discussed in <xref target="choose" />. 
</t>
</section>

<section title="SCTP and NATs">
<t>
The end-to-end path between a client and server MAY consist of one or more Network Address Translators (NATs) that manipulate address and port information in IP and SCTP headers. SCTP's association establishment and multihoming mechanisms pose unique challenges in the context of NATs. These issues are discussed in <xref target="I-D.stewart-behave-sctpnat" />.
</t>

</section>
</section>

<section anchor="acks" title="Acknowledgments">
<t>

</t>
</section>

</middle>

<back>

<!-- ************** REFERENCES *************** -->
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2116" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.1945" ?>
<?rfc include="reference.RFC.2616" ?>
<?rfc include="reference.I-D.ietf-tsvwg-sctpsocket" ?>
</references>

<references title="Informative References">
<?rfc include="reference.RFC.3758" ?>
<?rfc include="reference.I-D.stewart-tsvwg-sctpstrrst" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.I-D.stewart-behave-sctpnat" ?>

<reference anchor="NAS2008">
           <front>
               <title>Multistreamed Web Transport for Developing Regions
			   </title>
               <author initials="P." surname="Natarajan" fullname="Preethi Natarajan">
                   <organization abbrev="Udel">
                   University of Delaware
                   </organization>
               </author>
			   <author initials="P." surname="Amer" fullname="Paul Amer">
                   <organization abbrev="Udel">
                   University of Delaware
                   </organization>
				</author>
			   <author initials="R." surname="Stewart" fullname="Randall Stewart">
                   <organization abbrev="ResGroup">
                   The Resource Group
                   </organization>
               </author>
			   <date year="2008" />
           </front>
			<seriesInfo name="NSDR '08: Proceedings of the second ACM SIGCOMM workshop on Networked systems for developing regions, Seattle, WA, USA" value=""/>
</reference>

<reference anchor="N2008">
           <front>
               <title>Leveraging Innovative Transport Layer Services for Improved Application Performance
			   </title>
               <author initials="P." surname="Natarajan" fullname="Preethi Natarajan">
                   <organization abbrev="Udel">
                   University of Delaware
                   </organization>
				</author>
			   <date year="2008" />
           </front>
			<seriesInfo name="PhD Dissertation, in progress, Computer & Information Sciences Department, University of Delaware, USA" value=""/>
</reference>
			
<reference anchor="Movies" target="http://www.cis.udel.edu/~amer/PEL/leighton.movies/index.html">
           <front>
               <title>Movies Comparing HTTP over TCP vs. HTTP over SCTP Streams
			   </title>
               <author initials="" surname="" fullname="">
                 <organization />
			   </author>
		   <date year="2008" />
           </front>
</reference>
<reference anchor="FTY1999">
           <front>
               <title>The TIME_WAIT state in TCP and its effect on busy servers
			   </title>
               <author initials="T." surname="Faber" fullname="Theodore Faber">                
               </author>
			   <author initials="J." surname="Touch" fullname="Joe Touch">
  			   </author>
			   <author initials="W." surname="Yue" fullname="Wei Yue">
               </author>
			   <date year="1999" />
           </front>
			<seriesInfo name="INFOCOM '99: Proceedings of the IEEE INFOCOM Conference, pp. 1573-1583" value=""/>
</reference>

</references>

</back>

</rfc>