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-
load.
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
zero.
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
request.
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-
tent.
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
efficient.
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
packet.
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
GET.
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
session.
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]