Network Working Group                                       P. Natarajan
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                                 P. Amer
Expires: January 10, 2010                                    J. Leighton
                                                  University of Delaware
                                                                F. Baker
                                                           Cisco Systems
                                                            July 9, 2009


           Using SCTP as a Transport Layer Protocol for HTTP
                 draft-natarajan-http-over-sctp-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Natarajan, et al.       Expires January 10, 2010                [Page 1]


Internet-Draft                SCTP for HTTP                    July 2009


Abstract

   Hyper-Text Transfer Protocol (HTTP) [RFC2616] 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) [RFC4960].  Similar
   to TCP, SCTP offers a reliable end-to-end transport connection to
   applications.  Additionally, SCTP offers innovative services
   unavailable in TCP.  This draft (i) specifies HTTP over SCTP's
   multistreaming service, (ii) lists open issues warranting more
   discussion and/or investigation, and (iii) shares some lessons
   learned from implementing HTTP over SCTP.  Finally, this document
   highlights SCTP services that better match HTTP's needs than TCP.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Designing HTTP over SCTP Streams . . . . . . . . . . . . . . .  3
     3.1.  Number of SCTP Streams . . . . . . . . . . . . . . . . . .  4
     3.2.  Mapping HTTP Transactions to SCTP Streams  . . . . . . . .  5
   4.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Definition of Pipelining . . . . . . . . . . . . . . . . .  5
     4.2.  How does a Web client decide between TCP vs. SCTP? . . . .  6
     4.3.  SCTP and Chunked Encoding  . . . . . . . . . . . . . . . .  6
     4.4.  TCP-SCTP Gateway . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  SCTP and Middleboxes . . . . . . . . . . . . . . . . . . .  7
   5.  Lessons Learned from Implementing HTTP over SCTP . . . . . . .  7
     5.1.  Avoiding Dependencies in Message Transmission  . . . . . .  7
     5.2.  Order of Pipelined Requests and Responses  . . . . . . . .  8
     5.3.  Benefits for Progressive Images  . . . . . . . . . . . . .  8
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  SCTP Services for HTTP-based Applications . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12













Natarajan, et al.       Expires January 10, 2010                [Page 2]


Internet-Draft                SCTP for HTTP                    July 2009


1.  Introduction

   This draft specifies HTTP over SCTP.  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 new services including multistreaming, multihoming,
   message-oriented data transfer etc.

   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.  This document presents a design for mapping HTTP
   transactions over SCTP streams, and also highlights ongoing work and
   open issues that require further discussion and/or investigation
   within the httpbis community.

   HTTP over SCTP was implemented in the Apache Server and Firefox
   browser.  Some of the lessons learned during this implementation
   exercise are discussed.  Finally, this document discusses more SCTP
   services that are better suited to HTTP's needs than TCP services.


2.  Conventions

   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 [RFC2119].


3.  Designing HTTP over SCTP Streams

   In this document, an HTTP request (or response) is considered
   independent when its application-level processing does not depend on
   the availability of other HTTP requests (or responses).  The primary
   objective of our design is to exploit SCTP's multistreaming service
   to avoid HOL blocking between independent HTTP transactions.

   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-transaction HOL blocking.




Natarajan, et al.       Expires January 10, 2010                [Page 3]


Internet-Draft                SCTP for HTTP                    July 2009


   Two guidelines govern the HTTP over SCTP streams design discussed
   below: (i) to reduce deployment concerns, make no changes to the
   existing HTTP specification (such as the URI syntax), 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 [N2009].  The two components of this design
   are discussed next.

3.1.  Number of SCTP Streams

   SCTP streams are uni-directional; inbound and outbound streams carry
   data to and from each end point, respectively.  The number of inbound
   or outbound SCTP streams is negotiated during the association
   establishment phase (Figure 1).  Before association establishment,
   the number of inbound or outbound streams may be modified by using
   appropriate SCTP socket options [I-D.ietf-tsvwg-sctpsocket].  The
   stream "reset" functionality allows for re-negotiating the number of
   streams after association establishment
   [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 [RFC4960]).  However,
   for every outbound SCTP stream with id *a* on which the client
   transmits requests, there MUST be a corresponding inbound stream with
   id *a*.  Typically, this is achieved by opening an SCTP association
   with equal number of inbound and outbound streams.


                     Client                                    Server
                        |                                         |
                        |-----------INIT (IS=m,OS=m)------------->|
   #Streams = MIN (m,n) |<---------INIT-ACK (IS=n,OS=n)-----------| #Streams = MIN (m,n)
                        |                                         |
                        /                   .                     /
                        \                   .                     \
                        |                                         |
                        |--------HTTP REQUEST i (on OS a)-------->|
                        |<-------HTTP RESPONSE i (on OS a)--------|
                        |                                         |
   IS: Inbound Stream
   OS: Outbound Stream



                     Figure 1: HTTP over SCTP Streams





Natarajan, et al.       Expires January 10, 2010                [Page 4]


Internet-Draft                SCTP for HTTP                    July 2009


3.2.  Mapping HTTP Transactions to SCTP Streams

   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 Figure 1, the
   web client maps HTTP transaction *i* to SCTP stream *a*.  The client
   transmits HTTP request *i* on the client's outbound (server's
   inbound) SCTP stream *a*.  The web server transmits the corresponding
   response on the server's outbound (client's inbound) SCTP stream *a*.
   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.

   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 either (i) increase the number of SCTP streams in the association
   [I-D.stewart-tsvwg-sctpstrrst], such that, each transaction is
   transmitted on a different SCTP stream, or (ii) 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 HTTP 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.


4.  Open Issues

   This section discusses some of the open issues that require further
   discussion and/or investigation.

4.1.  Definition of Pipelining

   Section 8 of [RFC2616] notes that "HTTP requests and responses can be
   pipelined on a connection.  Pipelining allows a client to make
   multiple requests without waiting for each response, allowing a
   single TCP connection to be used much more efficiently, with much
   lower elapsed time."  Adapting this definiton of pipelining to HTTP
   over SCTP implies that transmitting multiple HTTP requests over an
   SCTP association (transport connection) without waiting for each



Natarajan, et al.       Expires January 10, 2010                [Page 5]


Internet-Draft                SCTP for HTTP                    July 2009


   response should be considered as pipelining, even if the requests are
   transmitted on different SCTP streams.  Ongoing discussion attempts
   to figure out if RFC2616's definition of pipelining is generic enough
   for any transport including SCTP, or if the definition is suitable
   only for TCP.

4.2.  How does a Web client decide between TCP vs. SCTP?

   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).  A web client uses one or
   more of the following options to decide between TCP vs. SCTP for an
   HTTP 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.  This approach is explored in
   [I-D.wing-http-new-tech].

   Option 2: [RFC3263] describes how SIP proxies and clients can select
   the transport protocol using SRV records [RFC2782].  A similar
   solution can be conceived for HTTP [H2008].

   Option 3: 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,
   "http-sctp://" or "https-sctp://"
   [I-D.wood-tae-specifying-uri-transports].

   While option 1 is simple and end-to-end, the other options require
   support from new protocols and/or infrastructure.  Also, using
   options 2 and 3, a web client can identify whether the web server
   supports SCTP but cannot determine if the middleboxes en-route
   support SCTP (discussed below).

4.3.  SCTP and Chunked Encoding

   SCTP's message-based transmission could be leveraged to avoid HTTP's
   chunked encoding feature.  Chunked encoding [RFC2616] allows
   dynamically generated HTTP messages to be transferred as a series of
   chunks, each with its own size indicator.  The current proposal is to
   use SCTP's Payload Protocol ID (PPID) -- an optional value set by the
   sender and read by the receiver, to avoid chunked encoding in HTTP
   over SCTP.  The approach would be to define two new SCTP PPID values
   (allocated by IANA) -- HTTP_MESSAGE_PIECE and HTTP_MESSAGE_END.  The
   sender sets PPID to HTTP_MESSAGE_PIECE for all but the last chunk of
   an HTTP object, and sets the last chunk's PPID to HTTP_MESSAGE_END.



Natarajan, et al.       Expires January 10, 2010                [Page 6]


Internet-Draft                SCTP for HTTP                    July 2009


   This proposal is under investigation.

4.4.  TCP-SCTP Gateway

   Research has shown that SCTP streams enable perceivable improvements
   to throughput and web response times, especially in high latency
   and/or lossy last hops such as satellite links [N2009].  A TCP-SCTP
   gateway allows web clients in such last hops to experience 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 or SCTP as
   discussed in Section 4.2.  Note that web proxies can also function as
   TCP-SCTP gateways.

4.5.  SCTP and Middleboxes

   SCTP's association establishment and multihoming mechanisms pose
   unique challenges in the context of NATs.  These issues are addressed
   in [I-D.ietf-behave-sctpnat].  The end-to-end path between a client
   and server MAY consist of one or more NATs and/or firewalls that do
   not support SCTP.  Until middleboxes support SCTP, UDP encapsulation
   is a possible solution [I-D.tuexen-sctp-udp-encaps].


5.  Lessons Learned from Implementing HTTP over SCTP

   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 [N2009].

5.1.  Avoiding Dependencies in Message Transmission

   Similar to UDP, SCTP preserves message boundaries and employs a
   fragmentation and reassembly algorithm to accomplish this.  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 delay transmission of
   the 1KB message.  The client or server application can avoid this
   delay 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, thus requiring no further fragmentation by SCTP.
   An application can use either the SCTP_PEER_ADDR or the SCTP_STATUS
   socket options to obtain an SCTP association's PMTU
   [I-D.ietf-tsvwg-sctpsocket].



Natarajan, et al.       Expires January 10, 2010                [Page 7]


Internet-Draft                SCTP for HTTP                    July 2009


5.2.  Order of Pipelined Requests and Responses

   Section 8 of [RFC2616] mandates that in HTTP 1.1 with pipelining, "a
   server MUST send its responses to those requests in the same order
   that the requests were received."  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 [N2009].
   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 *a* MUST match the order of transmitted HTTP
   requests within the corresponding outbound SCTP stream *a*.
   Consequently, within each SCTP stream, a web server MUST send its
   responses to those reqeusts in the same order that the requests were
   received.

5.3.  Benefits for Progressive Images

   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
   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 [NAS2008].  These page downloads were captured as
   movies and can be viewed at [Movies].


6.  Acknowledgments

   Thanks to Henrik Nordstorm, Dan Wing, and Andrew Yourtchenko for



Natarajan, et al.       Expires January 10, 2010                [Page 8]


Internet-Draft                SCTP for HTTP                    July 2009


   helping with the Open Issues Section.


7.  References

7.1.  Normative References

   [I-D.ietf-tsvwg-sctpsocket]
              Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
              Lei, "Sockets API Extensions for Stream Control
              Transmission Protocol (SCTP)",
              draft-ietf-tsvwg-sctpsocket-19 (work in progress),
              February 2009.

   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [RFC2116]  Apple, C. and K. Rossen, "X.500 Implementations
              Catalog-96", RFC 2116, April 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

7.2.  Informative References

   [FTY1999]  Faber, T., Touch, J., and W. Yue, "The TIME_WAIT state in
              TCP and its effect on busy servers", INFOCOM '99:
              Proceedings of the IEEE INFOCOM Conference, pp. 1573-
              1583 , 1999.

   [H2008]    Hardie, T., "Email Post to the APPS-DISCUSS Mailing List",
              (work in progress) , 2008.

   [I-D.ietf-behave-sctpnat]
              Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
              Transmission Protocol (SCTP) Network Address Translation",
              draft-ietf-behave-sctpnat-01 (work in progress),
              February 2009.

   [I-D.stewart-tsvwg-sctpstrrst]
              Stewart, R., Lei, P., and M. Tuexen, "Stream Control



Natarajan, et al.       Expires January 10, 2010                [Page 9]


Internet-Draft                SCTP for HTTP                    July 2009


              Transmission Protocol (SCTP) Stream Reconfiguration",
              draft-stewart-tsvwg-sctpstrrst-01 (work in progress),
              February 2009.

   [I-D.tuexen-sctp-udp-encaps]
              Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
              Packets", draft-tuexen-sctp-udp-encaps-02 (work in
              progress), November 2007.

   [I-D.wing-http-new-tech]
              Wing, D., Yourtchenko, A., and P. Natarajan, "Happy
              Eyeballs: Successful Introduction of New Technology to
              HTTP", (work in progress) , 2009.

   [I-D.wood-tae-specifying-uri-transports]
              Wood, L., "Specifying transport mechanisms in Uniform
              Resource Identifiers",
              draft-wood-tae-specifying-uri-transports-06 (work in
              progress), May 2009.

   [Movies]   "Movies Comparing HTTP over TCP vs. HTTP over SCTP
              Streams", 2008, <http://www.cis.udel.edu/~amer/PEL/
              leighton.movies/index.html>.

   [N2009]    Natarajan, P., "Leveraging Innovative Transport Layer
              Services for Improved Application Performance", PhD
              Dissertation, Computer & Information Sciences Department,
              University of Delaware, USA , 2009.

   [NAS2008]  Natarajan, P., Amer, P., and R. Stewart, "Multistreamed
              Web Transport for Developing Regions", NSDR '08:
              Proceedings of the second ACM SIGCOMM workshop on
              Networked systems for developing regions, Seattle, WA,
              USA , 2008.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)



Natarajan, et al.       Expires January 10, 2010               [Page 10]


Internet-Draft                SCTP for HTTP                    July 2009


              Partial Reliability Extension", RFC 3758, May 2004.


Appendix A.  SCTP Services for HTTP-based Applications

   This draft discussed how SCTP's multistreaming and message-based
   transmission could be adapted for HTTP.  This section lists other
   SCTP services.  The authors believe that the SCTP services listed
   below MAY help HTTP, but the details remain unclear at this time.


   1.  Four-way Handshake during Association Establishment.

       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.


   2.  No Maximum Segment Lifetime (MSL) during Association Termination.

       SCTP's association termination does not involve a TIME_WAIT state
       [RFC0793], since the Initiation and Verification tags help to
       associate SCTP Protocol Data Units (PDUs) with the corresponding
       SCTP associations [RFC4960].  Note that TCP's TIME_WAIT state
       increases memory and processing overload at a busy web server
       [FTY1999].


   3.  SCTP Multihoming for Improved Fault Tolerance.

       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.


   4.  Partial Reliability.

       Reference [RFC3758] describes PR-SCTP, an extenstion to
       [RFC4960], that enables partially reliable data transfer between



Natarajan, et al.       Expires January 10, 2010               [Page 11]


Internet-Draft                SCTP for HTTP                    July 2009


       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 Section 3 currently does not
       make use of this PR-SCTP service.


   5.  Unordered Data Delivery.

       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 Section 3 does not make use
       of this SCTP service.


Authors' Addresses

   Preethi Natarajan
   Cisco Systems
   425 East Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Email: prenatar@cisco.com











Natarajan, et al.       Expires January 10, 2010               [Page 12]


Internet-Draft                SCTP for HTTP                    July 2009


   Paul D. Amer
   University of Delaware
   Computer and Information Sciences Department
   Newark, DE  19716
   USA

   Phone: 302-831-1944
   Email: amer@cis.udel.edu


   Jonathan Leighton
   University of Delaware
   Computer and Information Sciences Department
   Newark, DE  19716
   USA

   Phone:
   Email: leighton@cis.udel.edu


   Fred Baker
   Cisco Systems
   1121 Via Del Rey
   Santa Barbara, CA  93117
   USA

   Phone:
   Email: fred@cisco.com























Natarajan, et al.       Expires January 10, 2010               [Page 13]