[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02                                                      
     INTERNET-DRAFT                                           Bernard Aboba
     <draft-aboba-rtp-http-01.txt>                    Microsoft Corporation
                    Payload Format for HTTP Encoding in RTP
     1.  Status of this Memo
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing 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.''
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     aboba-rtp-http-01.txt>, and  expires May 10, 1997.  Please  send  com-
     ments to the authors.
     2.  Abstract
     This  document  specifies  a  payload  format for use in encoding HTTP
     within RTP. This payload format can be used for unreliable  multicast-
     ing of resources such as Web pages, stock tickers, etc.  As with other
     RTP applications, receiver feedback and group  membership  information
     is provided via RTCP.
     3.  Introduction
     3.1.  Purpose
     Considerable  interest  has  recently  arisen  in  the multicasting of
     resources residing on HTTP servers.  Many of these uses can be  satis-
     fied by ureliable transmission.
     This document specifies a payload format suitable for encoding of HTTP
     within RTP. It is expected that this payload format will prove  useful
     for  unreliable multicasting of resources, either on a one-shot basis,
     or in a data carousel-style format, where  resources  are  continually
     re-multicast.  This specification is not expected to be used with uni-
     cast, since unicast applications will instead use HTTP over TCP.
     Aboba                                                         [Page 1]

     INTERNET-DRAFT                                         1 November 1996
     3.2.  Overview
     Multicasting of HTTP payloads is useful in a variety of  applications,
     and  as  a result, several approaches have been taken. One of these is
     to put a single resource within a payload; another is to pack multiple
     resources in a payload. If multiple resources are placed within a sin-
     gle payload, this can be accomplished either via encapsulation or  via
     a packing method such as MHTML, defined in [5].
     This  document  specifies  encapsulation of a single resource per pay-
     load.  As defined in this specification, the HTTP payload consists  of
     a preamble header, a MIME-like header, and entity-body content. Infor-
     mation on the resource being transmitted (such as the URI and the off-
     set)  is  placed  in  the  preamble  header  so  as to avoid requiring
     receivers to parse MIME-headers in the HTTP payload in order to deter-
     mine what portions of a resource have been received. As a result, this
     specification does not propose any new  MIME  headers,  and  any  MIME
     headers  allowable in an HTTP GET response may be enclosed in the pay-
     This simplifies construction of unicast-multicast proxies,  since  the
     MIME-like  header  in the payload can be identical to that returned in
     the response to an HTTP-GET request.  Proxies  may  therefore  make  a
     request  for  a  URL, stuff the response into a payload, and multicast
     it.  This is an efficient process since the proxy  does  not  need  to
     parse the response or construct an MHTML package.
     4.  RTP header
     Rather  than  defining  a new profile, this specification assumes that
     HTTP payloads will be transmitted using the  RTP  profile  defined  in
     [3],  that is the RTP profile for audio and video conferencing.  Addi-
     tional required parameters are accommodated via definition of an  HTTP
     payload  format.  As a result, there is no need for header extensions,
     SDES private extensions, new sender or  receiver  report  fields,  new
     RTCP packet types, or changes in the reporting interval constants.
     Nevertheless,  some  clarifications  are useful in describing how HTTP
     payload encoding is to be used with the profile defined in [3].
     4.1.  Extension bit
     Since this specification does not define header extensions for  encod-
     ing of HTTP payloads, the extension bit will typically be cleared.
     4.2.  CSRC count
     Since HTTP payloads do not require mixing, there is no need for a con-
     tributing source field. As a result, the CSRC count field  is  set  to
     Aboba                                                         [Page 2]

     INTERNET-DRAFT                                         1 November 1996
     4.3.  Marker Bit
     For  use with HTTP payloads, a zero marker bit is used to indicate the
     last packet for a resource.  The  first  packet  is  distinguished  by
     inclusion of a MIME -like header after the preamble header.
     4.4.  Payload types
     A  dynamic  payload  type  is  used.  As a result, there is no need to
     assign a static payload type.
     4.5.  SSRC
     Unlike with A/V payloads, a sender may use  a  single  synchronization
     source  for transmission of multiple HTTP payload streams. Thus a JPEG
     file may be transmitted with the same SSRC as an HTML file. This  does
     not present a problem since the timestamp is used to uniquely identify
     resource streams.
     4.6.  Timestamp
     Since a single synchronization source is used for transmission of mul-
     tiple resources, an additional parameter is needed to identify packets
     within the same resource. The URI was not felt to  be  sufficient  for
     this purpose, since a given resource may be multicast in data-carousel
     style, changing with each transmission.
     As a result, the RTP timestamp field is used for  this  purpose.   For
     use with HTTP payloads, the timestamp is constant for all packets that
     form a single transmission of a resource, and represents the  time  at
     which the sender began to transmit the resource.
     Due  to  out  of  order  delivery it is possible that packets from one
     resource will be intermingled with packets from another resource, sent
     to  the  same group and port. In this case the combination of the SSRC
     and timestamp can be used to demultiplex the resource stream.
     5.  HTTP Payload format
     HTTP payloads consist of a preamble header, a  MIME-like  header,  and
     entity-body content.
     The  purpose  of  the  preamble  header is identify the resource being
     sent, and to allow late joining receivers to calculate  which  portion
     of  the  resource  they  have  missed.  Depending  on the application,
     resources with missing portions will either be discarded or  a  repair
     request  will  be made. Since this specification is primarily intended
     for use in situations where a local repair may not be timely (such  as
     with a frequently updated stock ticker), or where the resource will be
     re-multicast, it is not clear that an RTCP  "NAK"  packet  is  needed.
     Aboba                                                         [Page 3]

     INTERNET-DRAFT                                         1 November 1996
     Therefore  repairs  are expected to be executed via a partial HTTP GET
     While MIME-like headers could be used for resource identification  (to
     provide information such as the URI, referring URI, content length and
     content range), prepending of a binary header reduces  the  amount  of
     parsing  required  to  get  at this critical information. The use of a
     preamble header has the additional benefit of not requiring  MIME-like
     headers to be present other than in the first packet. Thus, subsequent
     packets will typically contain only the preamble header and body  con-
     Thus,  rather  than  adding  MIME-like  headers,  it  is intended that
     senders will simply retransmit the MIME-like header  obtained  in  the
     HTTP GET response. Similarly, it is expected that the entity-body con-
     tent will be retransmitted without modification.
     5.1.  Preamble header
     The preamble header is comprised of a 4 octet fixed portion,  and  two
     variable-length strings.
                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     |                            Offset                             |
     |                            URI                              |0|
     |   URI     |0|              Referring URI                    |0|
     5.1.1.  Offset
     The offset field is 32-bits long. For a data packet, it represents the
     octet offset within the resource  identified  by  the  RTP  timestamp.
     Although  the  offset  field  will  typically increase with increasing
     sequence numbers, this need not always be the case, since portions  of
     a resource may be transmitted out of order. Receivers should therefore
     be prepared to handle packet ordering based on the offset rather  than
     the sequence number.
     While  the  offset information could have also been provided using the
     Content-range: HTTP response header, this would have  required  inser-
     tion  of  a  MIME-like  header within each packet, and parsing of this
     header by the receiver. It is felt that the offset mechanism  is  more
     Aboba                                                         [Page 4]

     INTERNET-DRAFT                                         1 November 1996
     5.1.2.  URI
     The URI field is a null-terminated string, representing the URI of the
     resource being transmitted. While it begins on a 32-bit  boundary,  it
     is not padded to such a boundary.
     Given the expected size of the URI and referring URI fields, the vari-
     able-length strings are expected to comprise the vast majority of  the
     preamble header. Given that each of the string fields may be 40 octets
     or larger in length, when the 28 octets of IP/UDP header and 12 octets
     of RTP header are added, the result may be 140 octets or more of over-
     head. This amount of overhead would be unacceptable if it were present
     in  every  packet.  It is therefore appropriate to ask whether the URI
     and referring URI fields  are  required  for  inclusion  within  every
     The  URI,  offset,  and packet length uniquely identify the portion of
     the resource being transmitted. Since receivers may join late, or miss
     portions of the transmission, receivers must be able to quickly bind a
     timestamp to a URI so that the incoming resource and missing  portions
     can be identified.
     However,  it is believed that this goal can be accomplished by placing
     the URI within the first packet of a  series,  and  then  only  within
     every  subsequent  nth packet. This results in a substantial reduction
     in overhead. For the purposes of this specification, it  is  suggested
     that n=4.
     For  packets  in which the URI is not included, a single null octet is
     used to indicate the missing field.
     5.1.3.  Referring URI
     The referring URI field is a null-terminated string, representing  the
     URI  of  the  resource referring to the resource being transmitted. It
     begins immediately after the null signifying the end of the URI field,
     and is not padded to a 32-bit boundary.
     The  referring  URI  is used to identify the resource referring to the
     resource being transmitted. This is used  by  late  joining  receivers
     wishing  to  retrieve  the context of the current transmission.  Typi-
     cally this is done via an HTTP GET request. However, in  the  case  of
     data-carousel transmission, this is not necessary, since the referring
     resource will be re-transmitted at a later time.
     As with the URI, the referring URI should not  be  transmitted  within
     every  packet. Instead, it should be placed within the first packet of
     a series, and then transmitted every 2n packets.
     For packets in which the referring URI is not included, a single  null
     octet is used to indicate the missing field.
     Aboba                                                         [Page 5]

     INTERNET-DRAFT                                         1 November 1996
     6.  Resource length
     The resource length is not included in the preamble header. Typically,
     this information is included within the first packet via the  Content-
     length:  header.  Although  it is possible that the first and/or final
     packet will be lost, we do not believe that the resource length justi-
     fies  inclusion  within  the  preamble  header.  This  is  because the
     receiver need not know the total length of the resource to make a par-
     tial GET request for the remainder of the resource.
     Note  that  it  is  possible  that the final packets of a resource are
     lost. In this case, the  receiver  will  note  that  it  has  not  yet
     received  a  packet  with  the marker bit indicating completion of the
     resource transmission, after waiting a suitable interval after  recep-
     tion of the last packet. This interval is determined by the receiver's
     estimate of his RTT to the sender. After this  interval  has  expired,
     the receiver will either wait for the re-multicasting of the resource,
     or will attempt to retrieve the missing portion  via  a  partial  HTTP
     7.  Layered Data Carousels
     Reference  [4]  discusses use of RTP in layered multicasting.  Layered
     multicasting provides for receiver-driven rate adaptation.  While this
     was originally proposed for use in transmission of audio and video, it
     can also be applied to data  carousel  style  transmissions.  In  this
     application, each of the layers transmits the same resource, beginning
     at a different offset. Receivers with sufficient  bandwidth  may  then
     subscribe to multiple groups, and receive the resource more quickly.
     Reference  [4]  proposes guidelines for group address and port alloca-
     tion, as well as modifications to RTP semantics suitable  for  alloca-
     tion of SSRC identifiers across layered streams. SDES packets are then
     sent only on the lowest layer. It is  expected  that  these  modifica-
     tions, once available, should be applicable to transmission of layered
     HTTP payloads.
     8.  Non-RTP means
     In addition to information transmitted within the RTP encoding, it  is
     expected that receivers will make use of session information transmit-
     ted by non-RTP means.
     For example,  the  existence  of  a  data-carousel  style  session  is
     expected  to be determined via SDP, transmitted in one of its encapsu-
     lations, such as SAP. The SDP announcement will provide information on
     the  bandwidth  allocated to the session, as well as the group address
     (or in the case of a multi-group session, addresses) allocated to  the
     The  SDP  announcement  will  also be expected to indicate whether the
     data carousel transmission  provides  for  re-multicast  of  the  same
     Aboba                                                         [Page 6]

     INTERNET-DRAFT                                         1 November 1996
     resource  (in  which  case receivers can make partial GET requests for
     the missing portion),  or  whether  it  provides  continually  updated
     information (in which case receivers missing a portion of the resource
     should make a GET request for the entire resource).
     9.  Acknowledgements
     Thanks to Peter Parnes of the University of Lulea, and Thomas Pfenning
     of Microsoft for useful discussions of this problem space.
     10.  References
     [1]   R.  Braden.   "Requirements for Internet hosts - application and
     support." STD 3, RFC 1123, IETF, October 1989.
     [2]  H. Schulzrinne, S. Casner, R. Frederick, V.  Jacobson.   "RTP:  A
     Transport  Protocol  for Real-Time Applications." RFC 1889, GMD Fokus,
     January 1996.
     [3]  H. Schulzrinne.  "RTP Profile for  Audio  and  Video  Conferences
     with Minimal Control." RFC 1890, GMD Fokus, January 1996.
     [4]   M.  F.  Speer,  S.  McCanne.  "RTP Usage with Layered Multimedia
     Streams."  draft-speer-avt-layered-video-01.txt,   Sun   Microsystems,
     LBNL, June 1996.
     [5]   J.  Palme,  A. Hopmann.  "MIME E-mail Encapsulation of Aggregate
     Documents,  such  as  HTML  (MHTML)."    draft-ietf-mhtml-spec-03.txt,
     Stockholm University/KTH, ResNova Software, August, 1996.
     [6]  E.  Levinson.   "The MIME Multipart/Related Content-type." draft-
     ietf-mhtml-related-00.txt, Xison, May, 1996.
     [7]  J. Palme.  "Sending HTML in E-mail, an informational supplement."
     draft-ietf-mhtml-info-03.txt,  Stockholm University/KTH, August, 1996.
     11.  Authors' Addresses
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     Aboba                                                         [Page 7]