Internet Engineering Task Force Shigeru Fukunaga - Oki
Internet Draft Hideaki Kimata - NTT
Document: draft-fukunaga-low-delay-rtcp-00.txt July 14, 2000
Low delay RTCP packet format for backward messages
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document describes a new RTCP packet format for carrying the
backward messages for error recovery; such as MPEG-4 Visual upstream
messages [2] and H.263 backward messages [3]. As these backward
messages are requested to deliver in low delay, a new RTCP profile of
low delay is defined.
1. Conventions used in this document
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 RFC-2119 [4].
2. Introduction
For real-time video transmission, using the backward messaging
functionality from the receiver to the transmitter is very effective
for the error recovery or the error resilience. Therefore many
technologies are discussed and developed in the past years. And some
valuable tools are included into some international standards. For
example, "NEWPRED" is one of the error resilience tools using the
backward messages, and it is defined in MPEG-4 Advanced Real Time
Simple (ARTS) profile [2] and H.263 Annex N [3]. "Intra refresh (IR)"
and "re-transmission" are also famous error resilience tools using
Fukunaga/Kimata [page 1]
Low delay RTCP format for backward messages July 2000
the backward messages. The backward channel messages of these
techniques should be transmitted in the framework of RTCP.
The performance of these techniques strongly depends on the delay of
the backward message transmission. The longer the transmission delay
is, the slower the error recovery is. Therefore it is desirable for
the backward messages to be transmitted without any additional delay.
On the other hand, however, the normal RTCP packet is defined to send
at constant timing with random delay [5]. This rule is an obstacle
for the low delay backward messages.
This draft defines a new RTCP profile that can transmit the backward
messages without any random delay in order to maximize the
performance of the error resilient backward messaging tools. The new
RTCP will be called "LD-RTCP" in this draft. This draft also
describes the congestion control for the LD-RTCP.
3. New profile of low delay RTCP
This section specifies the new profile of the low delay RTCP (LD-
RTCP). The LD-RTCP SHALL be treated as a completely different RTCP
from the normal RTCP; such as SR, RR and so on, in the following
points.
- Sending timing rule
- Prohibition of Multicast
- Congestion Control
- Calculation of RTCP sending interval
- Compound RTCP packet
3.1. Sending timing rule
The performance of the error resilience tools using backward messages
(such as NEWPRED, IR and re-transmission) is sensitive to the delay
of the backward message. Therefore, LD-RTCP packets SHALL be sent as
soon as possible, i.e. as soon as a packet loss is detected, without
adding any random delay.
3.2. Prohibition of Multicast
As the sending interval of LD-RTCP packet may be smaller than that of
the normal RTCP, the number of LD-RTCP packets may be larger than
that of the normal RTCP packets.
In order to avoid additional congestion, LD-RTCP SHALL NOT be used in
multicast.
3.3. Congestion control
The total amount of traffic of the backward messages in the error
resilience tools can be controlled in the receiver. The total amount
of the LD-RTCP SHALL be controlled so that it is lower than 5% of the
Fukunaga/Kimata [page 2]
Low delay RTCP format for backward messages July 2000
amount of the forward video data. Even during the congestion, the
amount of the LD-RTCP also SHALL be controlled under 5%.
To reduce the number of LD-RTCP packets, multiple backward messages
can be concatenated in the payload of one LD-RTCP packet.
And although a normal RTCP packet is transmitted with random delay,
the LD-RTCP packet transmission interval depends on the interval of
the receiving and decoding the forward video data. Both the
receiving interval of the video RTP packet and the decoding time for
each packet data have some jitter associated with them. Therefore
the LD-RTCP transmission interval has some jitter by itself. It is
effective for the congestion control, and there is no need to add any
random delay. This means that the amount of jitter is enough to
avoid another congestion in the case of Unicast.
3.4. Calculation of RTCP sending interval
LD-RTCP packets SHALL NOT be included for the calculation of the RTCP
sending intervals.
All LD-RTCP packets SHALL be ignored when analyzing the information
in the sender and receiver reports (SR and RR), and only normal RTCP
packets SHALL be used.
If the LD-RTCP packets were included in the calculation of RTCP
sending interval, the RR packets should be generated in the short
timing of the LD-RTCP packets. In this case, the interval of the RR
packets would be smaller than 5 seconds, and the number of the normal
RTCP packets is much increased. This is bad from the view point of
the congestion.
3.5. Compound RTCP packet
Multiple LD-RTCP packets MAY be concatenated without any intervening
separators to form a compound RTCP packet. Although the normal
compound RTCP packet SHOULD start with SR or RR packets, in the case
of compound LD-RTCP packet, other normal RTCP packets SHALL NOT be
included, and only LD-RTCP packets SHALL be included in one compound
LD-RTCP packet.
Fukunaga/Kimata [page 3]
Low delay RTCP format for backward messages July 2000
4. LD-RTCP packets definition
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| BMT | PT=LD_RTCP | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Backward Messages Payload (byte aligned) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP
packets as in RTP data packets.
padding (P): 1 bit
If the padding bit is set, this LD-RTCP packet contains some
additional padding octets at the end which are not part of the
control information. The last octet of the padding is a count
of how many padding octets should be ignored. In the case
several backward messages are mapped onto one LD-RTCP packet,
padding should only be required on the last individual message.
backward message type (BMT): 5 bits
Identifies the type of the backward messages.
0: forbidden
1: NEWPRED in MPEG-4 ARTS Profile
2: NEWPRED in H.263 Annex N
3-63: reserved
In this internet-draft, only the NEWPRED is assigned as the
candidate of the BMT for the moment. Some other tools using the
backward messages may be assigned in the future.
packet type (PT): 8 bits
The value of the packet type (PT) identifier is the constant
LD_RTCP (TBD).
SSRC: 32 bits
SSRC is the synchronization source identifier for the sender of
this packet.
Backward Message Payload: variable
The syntax and semantics of the backward messages are usually
defined in each standard. For example, the backward message of
NEWPRED is defined in ISO/IEC 14496-2 [2] and ITU-T H.263 [3].
All messages are byte aligned. Normally one backward message is
mapped onto one LD-RTCP packet, and several messages with same
BMT could be continuously mapped onto one LD-RTCP packet. One
message SHALL NOT be fragmented into different LD-RTCP packets.
Fukunaga/Kimata [page 4]
Low delay RTCP format for backward messages July 2000
If the syntax and semantics of some tools are not defined in
any standard, the special payload format will be defined here.
5. References
1. Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9,
RFC 2026, October 1996.
2. ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding
of audio-visual objects - Part2: Visual", July 2000.
3. ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication," January 1998.
4. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
5. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for real-time applications", RFC 1889,
January 1996.
6. Author's Addresses
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
Email: fukunaga444@oki.co.jp
Hideaki Kimata
Nippon Telegraph and Telephone Corporation
1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847 Japan.
Email: kimata@nttvdt.hil.ntt.co.jp
Fukunaga/Kimata [page 5]