Copyright (c) 2005, RealNetworks, Inc. All rights reserved.

RDT Feature level 3.0 
Design Specification

1 Introduction

This paper defines a set of changes to the RDT transport for release in the
next Vodafone deliverable. The primary impetus for these changes is the desire
to ensure good performance of sender-side congestion control mechanisms. While
we do not see RDT as a transport we will focus development on in the future, our
current RTP implementation does not support ARQ based error correction and this
mechanism is highly desirable for congestion management as well as handover/cell
reselection. Thus these changes constitute highly tactical improvements with
minimal impact on existing components in the field. 

2 References

[ 1 ] M. Handley, J. Padhye, S. Floyd, J. Widmer. TCP Friendly Rate Control 
(TFRC): Protocol Specification. RFC 3448, rfc3448.txt, January 2003.
[ 2 ] 3GPP TS 26.234 V5.3.0 Transparent end-to-end Packet-switched 
Streaming Service (PSS);Protocols and codecs(Release 5), December 2002
[ 3 ] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport 
Protocol for Real-Time Applications. RFC 1889, rfc1889.txt, January 1996.
[ 4 ] T. Friedman, R. Caceres, A. Clark. RTP Control Protocol Extended 
Reports (RTCP XR). draft-ietf-avt-rtcp-report-extns-06.txt, May 2003
[ 5 ] J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. RTP Retransmission
Payload Format, draft-ietf-avt-rtp-retransmission-08.txt, December 2002
[ 6 ] S. Casner, V. Jacobson. Compressing IP/UDP/RTP Headers for Low-
Speed Serial Links, RFC 2508, rfc2508.txt, February 1999
[ 7 ] C. Bormann, Editor. RObust Header Compression (ROHC): Framework 
and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, rfc3095.txt, 
July 2001
[ 8 ] R. Braden, Editor. Requirements for Internet Hosts -- Communication 
Layers. RFC 1122, rfc1122.txt, October 1989


3 Overview

The congestion control model being implemented in the server is based upon
an equation-based model, as in [ 1 ], in which congestion is managed at the
sender through feedback provided by the receiver. The two most important inputs
to this equation are loss history and propagation delay. These variables are
sufficient to characterize the link throughput dynamics in order to maintain a
maximum sustainable throughput. These variables, however, must be made
available frequently and accurately. Further, as delivery of media data becomes
initially bounded by network capacity rather than the consumption rate
mechanisms must be put in place to prevent buffer overrun on the receiver. 3GPP
SA4 has defined a model for achieving this. Annex G in [ 2 ] defines a video
buffer verifier to prevent receiver overflow, but this model allows for certain
ambiguities to arise in underflow situations. This proposed change addresses
issues in receiver buffer monitoring as well.

While the RDT transport already provides sufficient loss characterization,
it does not currently provide a sufficient basis for computing propagation
delay. While RDT NAK/ACK packets provide some estimation, it lacks a timeline
synchronization with the sender clock as appears in receiver reports from RTP [
3 ]. This solution defines a new packet requesting this synchronization
information. The change will result in a feedback frequency roughly equivalent
to TCP.

This change also defines a new semantic requirement for the receiver. We
define a way to ensure that live media packets lost en route to the sender do
not trigger a congestion event on the end receiver. This addresses issues
observed within a large live infrastructure in which packets in live delivery
spread a cascading effect to all connected receivers. 

These changes define a tactical improvement within the possibly short-term
future life of the RDT protocol. With an increased need to interoperate with
other client and server applications, convergence on the standard RTP transport
[ 3 ] is becoming more necessary as the focus of our development. This
observation should serve to frame the discussion on the changes to a short-term
window. At the point when error correction and QoS enabling extension to RTP
are standardized and available as in [ 4 ] and [ 5 ], as well as mechanisms for
header compression as in [ 6 ] and [ 7 ] become integrated in metworks, we will
consider the possibility of transitioning to RTP as the mainline delivery
mechanism.

4 Specification

The following specifications apply only if the RTSP header for both client
and server specify support for RDTFeatureLevel 3.0 or higher.

4.1 RDTTransportInfoRequestPacket

struct RDTTransportInfoRequestPacket
{
bit[1] dummy0; /* 0 */
bit[5] dummy1; /* 0 */
bit[1] request_rtt_info;
bit[1] request_buffer_info;
u_int16 packet_type; /* 0xff09 */

if (request_rtt_info == 1)
{
u_int32 request_time_ms;
}
}

The RDTTransportInfoRequestPacket serves as a request for propagation delay
information and/or receiver buffer state. This request packet MAY be issued by
either the sender or the receiver of media data, but if issued by the receiver
of data is MUST NOT set the request_buffer_info flag. The sender of the
request packets SHOULD meter their issuance so that the traffic generated does
not exceed the feedback of delayed ACK TCP as specified in [ 9 ]. The request
packet MAY be included as part of another RDT datagram (as part of an RDT data
packet, for instance), but SHOULD NOT be added if, in adding it, the datagram
exceeds the network's maximum segment size.

4.2 RDTTransportInfoResponsePacket

struct RDTBufferInfo
{
u_int16 stream_id;
u_int32 lowest_timestamp;
u_int32 highest_timestamp;
u_int32 bytes_buffered;
}

struct RDTTransportInfoResponsePacket
{
bit[1] dummy0; /* 0 */
bit[4] dummy1; /* 0 */
bit[1] has_rtt_info;
bit[1] is_delayed;
bit[1] has_buffer_info;
u_int16 packet_type; /* 0xff0a */

if (has_rtt_info == 1)
{
u_int32 request_time_ms;
if (is_delayed)
{
u_int32 response_time_ms;
}
}
if (has_buffer_info == 1)
{
u_int16 buffer_info_count;
RDTBufferInfo[buffer_info_count] buffer_info;
}
}

The RDTTransportInfoResponsePacket is issued in response to the
RDTTransportInfoRequestPacket and SHOULD contain responses for all requested
fields. Since these packets are generally delivered via an unreliable
channel, the server MUST NOT depend on the reception of any particular 
response.

4.2.1 has_rtt_info response

When has_rtt_info is set in the response packet, the response SHALL include
the request_time_ms from the request_time_ms field from the request packet it is
responding to. The response_time_ms field SHOULD be filled from the most
accurate clock available to the receiver and represent the elapsed time from the
receipt of the corresponding request packet. The receiver of this packet SHOULD
respond to every request. The response SHOULD be issued as soon as is feasible.

4.2.2 has_buffer_info response

When has_buffer_info is set in the response packet, the response MUST
include RDTBufferInfo structures for each for every stream established for that
RDT session. The order of those streams MUST correspond to the stream_id's from
the RDT session. Data within each RDTBufferInfo SHOULD contain data for all
packets in the stream not yet passed to the renderer. The receiver MUST ensure
that any packets with identical timestamps equal to the lowest_timestamp field
are associated together such that there instance when some but not all packets
of equal timestamp are included in the bytes_buffered field. The bytes_buffered
field MUST include only payload data and not any transport related headers. If
there are gaps in the sequence number space in the buffered data, then the
receiver SHOULD include an RDTNakPacket in the same datagram. If no packets are
currently in the receiver's buffer, the receiver MUST include the timestamp
value of the packet most recently sent to the renderer as both the
highest_timestamp and lowest_timestamp. If no data has been sent to the
renderer, the receiver MUST set both values to zero.

Example:

If the receiver has received the following packets and has not sent any to the renderer:

Seqno: 0 Stream: 0 TS: 0 Len: 400
Seqno: 0 Stream: 1 TS: 0 Len: 100
Seqno: 1 Stream: 0 TS: 0 Len: 400
Seqno: 1 Stream: 1 TS: 100 Len: 100
Seqno: 2 Stream: 1 TS: 100 Len: 100
Seqno: 2 Stream: 0 TS: 200 Len: 400

The receiver would include the following:

stream_id 0
lowest_timestamp 0
highest_timestamp 200
bytes_buffered 1200
stream_id 1
lowest_timestamp 0
highest_timestamp 100
bytes_buffered 300

On stream 0, since the first two sequence numbers have the same timestamp, the
buffer calculation must include both of them or neither of them, so the
following would be invalid:

stream_id 0
lowest_timestamp 0
highest_timestamp 200
bytes_buffered 800

the receiver should remove both at once as in:

stream_id 0
lowest_timestamp 100
highest_timestamp 200
bytes_buffered 400

4.3 Bandwidth Overhead for TransportInfo packets

The following is a short explanation of the expected bandwidth consumption
invoked from using the TransportInfo mechanism. We use as our example an
audio/video session over GPRS at 25kbps with an average packet size of 400
bytes. We also assume that the round trip time is probed on every other data
packet and that the buffer information is probed once per second.

For the downstream (request case) we have:

25kbps / 400 bytes per sec = 8 packets/sec / 2 = 4 request packets/sec

If the request packets are embedded with data packets then there is no UDP/IP
overhead added and we get:

4 packets/sec * 7 bytes = 28Bps = 0.218kbps = 0.8% of the media rate

For the upstream case (here the packets are generally sent individually, so we
will consider UDP/IP overhead for the rtt packets with the buffer_info combined
with one of the rtt)

((28 bytes IP header + 20 bytes UDP header + 11 bytes rrt_info) 
* 4 packets/sec)+ (30 bytes BufferInfo * 1 packet/sec) = 266 Bps 
= 2.078 kbps = 8.31% of the media rate

The percentage overhead should generally serve as an upper bound since the 
average packet size will tend to increase with bitrate.


4.4 Handling of NULL Packets

A NULL packet is defined as an RDT packet with a zero length data segment.
If the data sender is unable or chooses not to send a given data packet, it MUST
send a NULL packet with the corresponding sequence number instead. Upon receipt
of a NULL packet, the client MUST treat this segment as lost in respect to the
media render. It MUST NOT, however, treat the packet as lost in respect to
congestion. The client SHALL NOT reduce sending rate nor initiate a media
downshift upon receipt of a NULL packet. The client SHALL treat the sequence
number of received NULL packets as received in respect to reception bit field of
RDTAckPacket. In parsing the NULL packet, all fields other than stream_id and
seq_no SHALL be undefined. Any intermediate device proxying the delivery of RDT
data SHALL pass through a NULL packet as it would any other packet.

5 Revision History

0.1 06/26/03 Sean Robinson: Initial draft
0.9 07/02/03 Sean Robinson: Changed the the requirement for all requested fields from 
SHOULD to MUST. Clarified usage of response_time_ms
0.91 07/09/03 Sean Robinson: Added bandwidth usage section
$Log: RDT_Feature_Level_30.txt,v $
Revision 1.1 2005/07/22 21:44:40 rishimathew
Organizing Protocol project a little better

Revision 1.1 2005/05/12 00:02:17 mfrazier
added update RDT spec

Revision 1.3 2003/07/14 18:32:21 srobinson
Fixed buffer example

Revision 1.2 2003/07/11 18:03:05 srobinson
Made inclusion of response_time_ms depndent on is_delayed flag.
Changed response inclusion requirement for MUST to SHOULD.

Revision 1.1 2003/07/10 20:48:37 srobinson
Added buffer example
Fixed incorrect bandwidth calaculation
Specified empty buffer handling