INTERNET-DRAFT Octavio Medina
Internet Engineering Task Force Francis Dupont
Expires December 2000 Laurent Toutain
ENST Bretagne
A proposal for the use of ECN bits with UDP flows
<draft-medina-ecn-udp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document contains a proposal for the use of ECN bits with UDP
packets. For the moment, the presence of ECN bits in the IP header
of UDP streams is useless. These bits could be used to identify
IP/UDP/RTP encapsulated data at routers prior to header compression
and other specific operations.
1. Introduction
The use of RTP for the transport of audio and video flows is becoming
a current practice on the Internet. With the increase on the number
of applications generating this type of data, it becomes interesting
to consider how network nodes could be optimized to process these
Medina, Dupont, Toutain Expires December 2000 [Page 1]
INTERNET-DRAFT draft-medina-ecn-udp-00.txt July 2000
flows. The RTP protocol is based on Application Layer Framing
concepts. It means that only at the application level there exists
the knowledge and the capability to handle the information. The
network in this case can be seen as a black box and applications have
to adapt to its behavior. If such a mechanism corresponds to the
end-to-end approach used in the Internet, in some situations, it
might be a good idea to give to the network some knowledge of RTP
flows. The main case is header compression.
Header compression has been proposed to improve transmission rates
over slow links. The utility of the mechanism has been validated by
the large deployment of TCP/IP header compression [1], but also with
the use of a similar method to compress the combined RTP/UDP/IP
headers [2]. Having IPv6 consolidating itself as the network protocol
of tomorrow's Internet, it becomes even more attractive to perform
header compression. The IPv6 header is formed of 40 bytes without
extension headers [3]. For IP telephony flows, a popular application
today, a considerable overhead is introduced by IPv6 if we consider
that the payload of telephony packets is usually small. Header
compression may not be reserved to slow links, but it can also be
useful for communication between IPTel gateways for example.
In order to perform compression, network nodes need first to identify
the protocol suite contained in the packet. In the case of RTP, nodes
need to find the UDP header (which may be a little complex in IPv6 if
extensions are used) and then look for an RTP header. This operation
is performed for every packet crossing the interface. Having a
standard and simple method to identify RTP/UDP/IP packets could
reduce the computing power needed to cleverly forward these type of
flows.
2. Proposal
This draft proposes the use of a flag in the IP header to indicate
the presence of RTP/UDP/IP headers in the packet. We propose to use
the CU (Currently Unused) bits in the DS field [4] for both IPv4 and
IPv6. The CU bits could potentially be used for Early Congestion
Notification [5] in the near future. Our proposal does not affect the
operation of this mechanism.
In the proposal to add Explicit Congestion Notification (ECN) [5] the
semantic of the CU bits is defined as:
- ECT (ECN-Capable Transport: bit 6 of the DiffServ Byte)
announces to the router that the source and the
destination can do explicit congestion notification.
- CE (Congestion Experienced: Bit 7 of the DiffServ Byte)
indicates a congestion on the path.
We propose to extend this semantic to UDP packets. We consider two
approaches:
Medina, Dupont, Toutain Expires December 2000 [Page 2]
INTERNET-DRAFT draft-medina-ecn-udp-00.txt July 2000
First Approach: CU bits: 1x, protocol: UDP.
indicates an RTP stream with congestion control.
This approach supposes the use of the ECN method for RTP flows. This
approach implies the implementation of TCP-friendly methods at the
application level, to be performed by RTP senders/receivers.
Second Approach: CU bits: 01.
indicates an RTP stream without congestion control.
This second option consists in adding a flag in the IP header to
identify non-adaptive RTP flows. The proposed bit combination is not
used by ECN, therefore its use should be transparent to the
mechanism. This flag could mainly be used to accelerate packet
classification prior to header compression. Alternatively, the
explicit indication of non-adaptive flows could be used by queue
management mechanisms such as RED [6] to better protect TCP-friendly
flows by dropping non-adaptive packets first when congestion is
experienced. Of course, the relationship between such an idea and the
ongoing works on DiffServ needs to be studied.
3. Tunneling
The mapping of DSCP and ECN values over tunneling interfaces is a
question. The mapping of the proposed "RTP flag" between
encapsulating and encapsulated headers follow the same principles as
those presented in [7].
4. Security Considerations
This proposal introduces no new security issue, section 9 of the ECN
document and the whole [7] deal with security considerations for ECN.
5. References
[1] V. Jacobson; "TCP/IP Compression for Low-Speed Serial Links",
RFC 1144; February 1990.
[2] S. Casner, V. Jacobson; "Compressing IP/UDP/RTP Headers for Low-Speed
Serial Links"; RFC 2508; February 1999.
[3] S. Deering, R. Hinden; "Internet Protocol, Version 6 Specification";
RFC 1883, December 1995.
[4] K. Nichols, S. Blade et al; "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers"; RFC 2474; December 1998.
[5] K. Ramakrishnan, S. Floyd; "A Proposal to add Explicit Congestion
Medina, Dupont, Toutain Expires December 2000 [Page 3]
INTERNET-DRAFT draft-medina-ecn-udp-00.txt July 2000
Notification (ECN) to IP"; RFC 2481; January 1999.
[6] S. Floyd, V. Jacobson; "Random Early Detection gateways for Congestion
Avoidance"; IEEE/ACM Transactions on Networking, Volume 1, Number 4,
August 1993, pp. 397-413.
[7] S. Floyd, K. K. Ramakrishnan; "ECN Interactions with IP Tunnels";
draft-floyd-ecn-tunnels-00.txt; April 2000.
8. Authors' Address
Octavio MEDINA,
Francis DUPONT,
Laurent TOUTAIN
Ecole Nationale des Tlcommunications de Bretagne
Campus de Rennes
3, rue de la Chtaigneraie
35510 CESSON-SEVIGNE
France
Email: {medina, dupont, toutain}@rennes.enst-bretagne.fr
Medina, Dupont, Toutain Expires December 2000 [Page 4]