draft-ietf-tsvwg-rtcweb-qos-15.txt   draft-ietf-tsvwg-rtcweb-qos-16.txt 
Network Working Group P. Jones Network Working Group P. Jones
Internet-Draft S. Dhesikan Internet-Draft S. Dhesikan
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: September 19, 2016 Cisco Systems Expires: November 12, 2016 Cisco Systems
D. Druta D. Druta
AT&T AT&T
March 18, 2016 May 11, 2016
DSCP and other packet markings for WebRTC QoS DSCP Packet Markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-15 draft-ietf-tsvwg-rtcweb-qos-16
Abstract Abstract
Many networks, such as service provider and enterprise networks, can Many networks, such as service provider and enterprise networks, can
provide different forwarding treatments for individual packets based provide different forwarding treatments for individual packets based
on Differentiated Services Code Point (DSCP) values on a per-hop on Differentiated Services Code Point (DSCP) values on a per-hop
basis. This document provides the recommended DSCP values for web basis. This document provides the recommended DSCP values for web
browsers to use for various classes of WebRTC traffic. browsers to use for various classes of WebRTC traffic.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2016. This Internet-Draft will expire on November 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Relation to Other Specifications . . . . . . . . . . . . . . 3 2. Relation to Other Specifications . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5 5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Downward References . . . . . . . . . . . . . . . . . . . . . 7 8. Downward References . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Document History . . . . . . . . . . . . . . . . . . . . . . 8 11. Document History . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Differentiated Services Code Point (DSCP) [RFC2474] packet marking Differentiated Services Code Point (DSCP) [RFC2474] packet marking
can help provide QoS in some environments. This specification can help provide QoS in some environments. This specification
provides default packet marking for browsers that support WebRTC provides default packet marking for browsers that support WebRTC
applications, but does not change any advice or requirements in other applications, but does not change any advice or requirements in other
IETF RFCs. The contents of this specification are intended to be a IETF RFCs. The contents of this specification are intended to be a
simple set of implementation recommendations based on the previous simple set of implementation recommendations based on the previous
RFCs. RFCs.
There are many use cases where such marking does not help, but it Networks where these DSCP markings are beneficial (likely to improve
seldom makes things worse if packets are marked appropriately. There QoS for WebRTC traffic) include:
are some environments where DSCP markings frequently help, though.
These include:
1. Private, wide-area networks. Network administrators have control 1. Private, wide-area networks. Network administrators have control
over remarking packets and treatment of packets. over remarking packets and treatment of packets.
2. Residential Networks. If the congested link is the broadband 2. Residential Networks. If the congested link is the broadband
uplink in a cable or DSL scenario, often residential routers/NAT uplink in a cable or DSL scenario, often residential routers/NAT
support preferential treatment based on DSCP. support preferential treatment based on DSCP.
3. Wireless Networks. If the congested link is a local wireless 3. Wireless Networks. If the congested link is a local wireless
network, marking may help. network, marking may help.
There are cases where these DSCP markings do not help, but, aside
from possible priority inversion for "less than best effort traffic"
(see Section 5), they seldom make things worse if packets are marked
appropriately.
DSCP values are in principle site specific, with each site selecting DSCP values are in principle site specific, with each site selecting
its own code points for controlling per-hop-behavior to influence the its own code points for controlling per-hop-behavior to influence the
QoS for transport-layer flows. However in the WebRTC use cases, the QoS for transport-layer flows. However in the WebRTC use cases, the
browsers need to set them to something when there is no site specific browsers need to set them to something when there is no site specific
information. In this document, "browsers" is used synonymously with information. In this document, "browsers" is used synonymously with
"Interactive User Agent" as defined in the HTML specification, "Interactive User Agent" as defined in the HTML specification,
[W3C.REC-html5-20141028]. This document describes a subset of DSCP [W3C.REC-html5-20141028]. This document describes a subset of DSCP
code point values drawn from existing RFCs and common usage for use code point values drawn from existing RFCs and common usage for use
with WebRTC applications. These code points are solely defaults. with WebRTC applications. These code points are intended to be the
default values used by a WebRTC application. While other values
could be used, using a non-default value may result in unexpected
per-hop behavior. It is RECOMMENDED that WebRTC applications use
non-default values only in private networks that are configured to
use different values.
This specification defines inputs that are provided by the WebRTC This specification defines inputs that are provided by the WebRTC
application hosted in the browser that aid the browser in determining application hosted in the browser that aid the browser in determining
how to set the various packet markings. The specification also how to set the various packet markings. The specification also
defines the mapping from abstract QoS policies (flow type, priority defines the mapping from abstract QoS policies (flow type, priority
level) to those packet markings. level) to those packet markings.
2. Relation to Other Specifications 2. Relation to Other Specifications
This document is a complement to [RFC7657], which describes the This document is a complement to [RFC7657], which describes the
skipping to change at page 4, line 40 skipping to change at page 4, line 48
the same 5-tuple, with each having a different level of importance to the same 5-tuple, with each having a different level of importance to
the application and, therefore, potentially marked using different the application and, therefore, potentially marked using different
DSCP values than another RTP stream or data channel within the same DSCP values than another RTP stream or data channel within the same
transport-layer flow. (Note that there are restrictions with respect transport-layer flow. (Note that there are restrictions with respect
to marking different data channels carried within the same SCTP to marking different data channels carried within the same SCTP
association as outlined in Section 5.) association as outlined in Section 5.)
The following are the inputs provided by the WebRTC application to The following are the inputs provided by the WebRTC application to
the browser: the browser:
o Flow Type: The browser provides this input as it knows if the flow o Flow Type: The application provides this input because it knows if
is audio, interactive video with or without audio, non-interactive the flow is audio, interactive video [RFC4594] [G.1010] with or
video with or without audio, or data. without audio, or data.
o Application Priority: Another input is the relative importance of o Application Priority: Another input is the relative importance of
an RTP stream or data channel. Many applications have multiple an RTP stream or data channel. Many applications have multiple
flows of the same Flow Type and often some flows are more flows of the same Flow Type and often some flows are more
important than others. For example, in a video conference where important than others. For example, in a video conference where
there are usually audio and video flows, the audio flow may be there are usually audio and video flows, the audio flow may be
more important than the video flow. JavaScript applications can more important than the video flow. JavaScript applications can
tell the browser whether a particular flow is high, medium, low or tell the browser whether a particular flow is high, medium, low or
very low importance to the application. very low importance to the application.
[I-D.ietf-rtcweb-transports] defines in more detail what an [I-D.ietf-rtcweb-transports] defines in more detail what an
individual flow is within the WebRTC context and priorities for media individual flow is within the WebRTC context and priorities for media
and data flows. and data flows.
Currently in WebRTC, media sent over RTP is assumed to be interactive
[I-D.ietf-rtcweb-transports] and browser APIs do not exist to allow
an application to to differentiate between interactive and non-
interactive video.
5. DSCP Mappings 5. DSCP Mappings
The DSCP values for each flow type of interest to WebRTC based on The DSCP values for each flow type of interest to WebRTC based on
application priority are shown in the following table. These values application priority are shown in the following table. These values
are based on the framework and recommended values in [RFC4594]. A are based on the framework and recommended values in [RFC4594]. A
web browser SHOULD use these values to mark the appropriate media web browser SHOULD use these values to mark the appropriate media
packets. More information on EF can be found in [RFC3246]. More packets. More information on EF can be found in [RFC3246]. More
information on AF can be found in [RFC2597]. DF is default information on AF can be found in [RFC2597]. DF is default
forwarding which provides the basic best effort service [RFC2474]. forwarding which provides the basic best effort service [RFC2474].
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
| Flow Type | Very | Low | Medium | High | | Flow Type | Very | Low | Medium | High |
| | Low | | | | | | Low | | | |
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
| Audio | CS1 | DF | EF (46) | EF (46) | | Audio | CS1 | DF | EF (46) | EF (46) |
| | (8) | (0) | | | | | (8) | (0) | | |
| | | | | | | | | | | |
| Interactive Video with | CS1 | DF | AF42, AF43 | AF41, AF42 | | Interactive Video with | CS1 | DF | AF42, AF43 | AF41, AF42 |
| or without audio | (8) | (0) | (36, 38) | (34, 36) | | or without Audio | (8) | (0) | (36, 38) | (34, 36) |
| | | | | | | | | | | |
| Non-Interactive Video | CS1 | DF | AF32, AF33 | AF31, AF32 | | Non-Interactive Video | CS1 | DF | AF32, AF33 | AF31, AF32 |
| with or without audio | (8) | (0) | (28, 30) | (26, 28) | | with or without Audio | (8) | (0) | (28, 30) | (26, 28) |
| | | | | | | | | | | |
| Data | CS1 | DF | AF11 | AF21 | | Data | CS1 | DF | AF11 | AF21 |
| | (8) | (0) | | | | | (8) | (0) | | |
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
Table 1: Recommended DSCP Values for WebRTC Applications Table 1: Recommended DSCP Values for WebRTC Applications
The application priority, indicated by the columns "very low", "low", The application priority, indicated by the columns "very low", "low",
"Medium", and "high", signifies the relative importance of the flow "Medium", and "high", signifies the relative importance of the flow
within the application. It is an input that the browser receives to within the application. It is an input that the browser receives to
skipping to change at page 6, line 20 skipping to change at page 6, line 35
Implementers should also note that excess EF traffic is dropped. Implementers should also note that excess EF traffic is dropped.
This could mean that a packet marked as EF may not get through, This could mean that a packet marked as EF may not get through,
although the same packet marked with a different DSCP value would although the same packet marked with a different DSCP value would
have gotten through. This is not a flaw, but how excess EF traffic have gotten through. This is not a flaw, but how excess EF traffic
is intended to be treated. is intended to be treated.
The browser SHOULD first select the flow type of the flow. Within The browser SHOULD first select the flow type of the flow. Within
the flow type, the relative importance of the flow SHOULD be used to the flow type, the relative importance of the flow SHOULD be used to
select the appropriate DSCP value. select the appropriate DSCP value.
Currently, all WebRTC video is assumed to be interactive
[I-D.ietf-rtcweb-transports], for which the Interactive Video DSCP
values in Table 1 SHOULD be used. Browsers MUST NOT use the AF3x
DSCP values (for Non-Interactive Video in Table 1) for WebRTC
applications. Non-browser implementations of WebRTC MAY use the AF3x
DSCP values for video that is known not to be interactive, e.g., all
video in a WebRTC video playback application that is not implemented
in a browser.
The combination of flow type and application priority provides The combination of flow type and application priority provides
specificity and helps in selecting the right DSCP value for the flow. specificity and helps in selecting the right DSCP value for the flow.
All packets within a flow SHOULD have the same application priority. All packets within a flow SHOULD have the same application priority.
In some cases, the selected application priority cell may have In some cases, the selected application priority cell may have
multiple DSCP values, such as AF41 and AF42. These offer different multiple DSCP values, such as AF41 and AF42. These offer different
drop precedences. The different drop precedence values provides drop precedences. The different drop precedence values provides
additional granularity in classifying packets within a flow. For additional granularity in classifying packets within a flow. For
example, in a video conference, the video flow may have medium example, in a video conference the video flow may have medium
application priority. If so, either AF42 or AF43 may be selected. application priority, thus either AF42 or AF43 may be selected. More
If the I-frames in the stream are more important than the P-frames, important video packets (e.g., a video picture or frame encoded
then the I-frames can be marked with AF42 and the P-frames marked without any dependency on any prior pictures or frames) might be
with AF43. (See Section 3 of [RFC6386] for a description of video marked with AF42 and less important packets (e.g., a video picture or
frame types.) frame encoded based on the content of one or more prior pictures or
frames) might be marked with AF43 (e.g., receipt of the more
important packets enables a video renderer to continue after one or
more packets are lost).
It is worth noting that the application priority is utilized by the It is worth noting that the application priority is utilized by the
coupled congestion control mechanism for media flows per coupled congestion control mechanism for media flows per
[I-D.ietf-rmcat-coupled-cc] and the SCTP scheduler for data channel [I-D.ietf-rmcat-coupled-cc] and the SCTP scheduler for data channel
traffic per [I-D.ietf-rtcweb-data-channel]. traffic per [I-D.ietf-rtcweb-data-channel].
For reasons discussed in Section 6 of [RFC7657], if multiple flows For reasons discussed in Section 6 of [RFC7657], if multiple flows
are multiplexed using a reliable transport (e.g., TCP) then all of are multiplexed using a reliable transport (e.g., TCP) then all of
the packets for all flows multiplexed over that transport-layer flow the packets for all flows multiplexed over that transport-layer flow
MUST be marked using the same DSCP value. Likewise, all WebRTC data MUST be marked using the same DSCP value. Likewise, all WebRTC data
skipping to change at page 8, line 7 skipping to change at page 8, line 34
This specification contains a downwards reference to [RFC4594] and This specification contains a downwards reference to [RFC4594] and
[RFC7657]. However, the parts of the former RFC used by this [RFC7657]. However, the parts of the former RFC used by this
specification are sufficiently stable for this downward reference. specification are sufficiently stable for this downward reference.
The guidance in the latter RFC is necessary to understand the The guidance in the latter RFC is necessary to understand the
Diffserv technology used in this document and the motivation for the Diffserv technology used in this document and the motivation for the
recommended DSCP values and procedures. recommended DSCP values and procedures.
9. Acknowledgements 9. Acknowledgements
Thanks to David Black, Magnus Westerland, Paolo Severini, Jim Thanks to David Black, Magnus Westerlund, Paolo Severini, Jim
Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tuexen, and Brian Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tuexen, and Brian
Carpenter for their invaluable input. Carpenter for their invaluable input.
10. Dedication 10. Dedication
This document is dedicated to the memory of James Polk, a long-time This document is dedicated to the memory of James Polk, a long-time
friend and colleague. James made important contributions to this friend and colleague. James made important contributions to this
specification, including serving initially as one of the primary specification, including serving initially as one of the primary
authors. The IETF global community mourns his loss and he will be authors. The IETF global community mourns his loss and he will be
missed dearly. missed dearly.
skipping to change at page 8, line 49 skipping to change at page 9, line 29
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-26 (work in progress), March draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2016. 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-transports] [I-D.ietf-rtcweb-transports]
Alvestrand, H., "Transports for WebRTC", draft-ietf- Alvestrand, H., "Transports for WebRTC", draft-ietf-
rtcweb-transports-11 (work in progress), January 2016. rtcweb-transports-12 (work in progress), March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, DOI Guidelines for DiffServ Service Classes", RFC 4594, DOI
10.17487/RFC4594, August 2006, 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, DOI (Diffserv) and Real-Time Communication", RFC 7657, DOI
10.17487/RFC7657, November 2015, 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>. <http://www.rfc-editor.org/info/rfc7657>.
12.2. Informative References 12.2. Informative References
[G.1010] International Telecommunications Union, "End-user
multimedia QoS categories", Recommendation ITU-T G.1010,
November 2001.
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-00 control for RTP media", draft-ietf-rmcat-coupled-cc-02
(work in progress), September 2015. (work in progress), April 2016.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
10.17487/RFC2474, December 1998, 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/ "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/
RFC2597, June 1999, RFC2597, June 1999,
skipping to change at page 10, line 5 skipping to change at page 10, line 37
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <http://www.rfc-editor.org/info/rfc3662>.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011,
<http://www.rfc-editor.org/info/rfc6386>.
[W3C.REC-html5-20141028] [W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O&#039;Connor, E., and S. Pfeiffer, "HTML5", Navara, E., O&#039;Connor, E., and S. Pfeiffer, "HTML5",
World Wide Web Consortium Recommendation REC- World Wide Web Consortium Recommendation REC-
html5-20141028, October 2014, html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>. <http://www.w3.org/TR/2014/REC-html5-20141028>.
Authors' Addresses Authors' Addresses
Paul E. Jones Paul E. Jones
 End of changes. 20 change blocks. 
35 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/