draft-ietf-bmwg-dsmterm-07.txt   draft-ietf-bmwg-dsmterm-08.txt 
Network Working Group Jerry Perser Network Working Group Jerry Perser
INTERNET-DRAFT Spirent INTERNET-DRAFT Spirent
Expires in: December 2003 David Newman Expires in: April 2004 David Newman
Network Test Network Test
Sumit Khurana Sumit Khurana
Telcordia Telcordia
Shobha Erramilli Shobha Erramilli
QNetworx QNetworx
Scott Poretsky Scott Poretsky
Avici Systems Avici Systems
June 2003 October 2003
Terminology for Benchmarking Network-layer Terminology for Benchmarking Network-layer
Traffic Control Mechanisms Traffic Control Mechanisms
<draft-ietf-bmwg-dsmterm-07.txt> <draft-ietf-bmwg-dsmterm-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.2.2 Conforming Packet ......................................8 3.2.2 Conforming Packet ......................................8
3.2.3 Nonconforming Packet ...................................9 3.2.3 Nonconforming Packet ...................................9
3.2.4 Forwarding Delay .......................................9 3.2.4 Forwarding Delay .......................................9
3.2.5 Jitter ................................................11 3.2.5 Jitter ................................................11
3.2.6 Undifferentiated Response .............................11 3.2.6 Undifferentiated Response .............................11
3.3 Sequence Tracking 3.3 Sequence Tracking
3.3.1 In-sequence Packet ....................................12 3.3.1 In-sequence Packet ....................................12
3.3.2 Out-of-order Packet ...................................12 3.3.2 Out-of-order Packet ...................................12
3.3.3 Duplicate Packet ......................................13 3.3.3 Duplicate Packet ......................................13
3.3.4 Stream ................................................14 3.3.4 Stream ................................................14
3.3.5 Test Sequence number .................................14 3.3.5 Test Sequence number .................................15
3.4 Vectors ...................................................15 3.4 Vectors ...................................................15
3.4.1 Intended Vector .......................................15 3.4.1 Intended Vector .......................................15
3.4.2 Offered Vector ........................................16 3.4.2 Offered Vector ........................................16
3.4.3 Expected Vectors 3.4.3 Expected Vectors
3.4.3.1 Expected Forwarding Vector ........................16 3.4.3.1 Expected Forwarding Vector ........................16
3.4.3.2 Expected Loss Vector ..............................17 3.4.3.2 Expected Loss Vector ..............................17
3.4.3.3 Expected Sequence Vector ..........................18 3.4.3.3 Expected Sequence Vector ..........................18
3.4.3.4 Expected Instantaneous Delay Vector ...............18 3.4.3.4 Expected Instantaneous Delay Vector ...............18
3.4.3.5 Expected Average Delay Vector .....................19 3.4.3.5 Expected Average Delay Vector .....................19
3.4.3.6 Expected Maximum Delay Vector .....................10 3.4.3.6 Expected Maximum Delay Vector .....................10
skipping to change at page 6, line 44 skipping to change at page 6, line 44
3.1.4 Congestion Management 3.1.4 Congestion Management
Definition: Definition:
An implementation of one or more per-hop-behaviors to avoid An implementation of one or more per-hop-behaviors to avoid
or minimize the condition of congestion. or minimize the condition of congestion.
Discussion: Discussion:
Congestion management may seek either to control congestion Congestion management may seek either to control congestion
or avoid it altogether. Such mechanisms classify packets or avoid it altogether. Such mechanisms classify packets
based upon IP Precedence or DSCP settings in a packet's IP based upon IP Precedence or DSCP settings in a packets IP
header. header.
Congestion avoidance mechanisms seek to prevent congestion Congestion avoidance mechanisms seek to prevent congestion
before it actually occurs. before it actually occurs.
Congestion control mechanisms gives one or flows (with a Congestion control mechanisms give one or more flows (with a
discrete IP Precedence or DSCP value) preferential treatment discrete IP Precedence or DSCP value) preferential treatment
over other classes during periods of congestion. over other classes during periods of congestion.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
skipping to change at page 7, line 49 skipping to change at page 7, line 49
See Also: See Also:
Microflow [Ni98] Microflow [Ni98]
Streams Streams
3.2 Measurement Terms 3.2 Measurement Terms
3.2.1 Channel Capacity 3.2.1 Channel Capacity
Definition: Definition:
The maximum forwarding rate [Ma98] at which none of the The number of packets per second that a device can be
offered packets are dropped by the DUT/SUT. observed to successfully transmit to the correct destination
interface in response to a specified offered load while the
device drops none of the offered packets.
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
Discussion: Discussion:
Channel capacity measures the packet rate at the egress Channel Capacity measures the packet rate at the egress
interface(s) of the DUT/SUT. In contrast, throughput as interface(s) of the DUT/SUT. In contrast, throughput as
defined in RFC 1242 measures the packet rate at the ingress defined in RFC 1242 measures the frame rate at the ingress
interface(s) of the DUT/SUT. interface(s) of the DUT/SUT.
Ingress-based measurements do not account for congestion of Ingress-based measurements do not account for queuing of the
the DUT/SUT. Channel capacity, as an egress measurement, DUT/SUT. Throughput rates can be higher than the Channel
does take congestion into account. Capacity because of queuing. The difference is dependent
upon test duration, packet rate, and queue size. Channel
Capacity, as an egress measurement, does take queuing into
account.
Understanding channel capacity is a necessary precursor to Understanding Channel Capacity is a necessary precursor to
any measurement involving forwarding congestion. Throughput any measurement involving Traffic Control Mechanisms. The
numbers can be higher than channel capacity because of accompanying methodology document MUST take into
queuing. consideration Channel Capacity when determining the expected
forwarding vectors. When the sum of the expected forwarding
vectors on an interface exceeds the Channel Capacity, the
Channel Capacity will govern the forwarding rate.
This measurement differs from forwarding rate at maximum This measurement differs from forwarding rate at maximum
offered load (FRMOL) [Ma98] in that it is intolerant of loss. offered load (FRMOL) [Ma98] in that Channel Capacity requires
zero loss.
Measurement units: Measurement units:
N-octet packets per second N-octet packets per second
See Also: See Also:
Throughput [Br91] Throughput [Br91]
Forwarding Rate at Maximum Offered Load [Ma98] Forwarding Rate at Maximum Offered Load [Ma98]
Channel Capacity [Sh48]
3.2.2 Conforming Packet 3.2.2 Conforming Packet
Definition: Definition:
Packets which lie within specific rate, delay, or jitter Packets which lie within specific rate, delay, or jitter
bounds. bounds.
Discussion: Discussion:
A DUT/SUT may be configured to allow a given traffic class to A DUT/SUT may be configured to allow a given traffic class to
consume a given amount of bandwidth, or to fall within consume a given amount of bandwidth, or to fall within
predefined delay or jitter boundaries. All packets that lie predefined delay or jitter boundaries. All packets that lie
within specified bounds are then said to be conforming, within specified bounds are then said to be conforming,
whereas those outside the bounds are nonconforming. whereas those outside the bounds are nonconforming.
Measurement units: Measurement units:
n/a n/a
Network-layer Traffic Control Mechanisms
See Also: See Also:
Expected Vector Expected Vector
Forwarding Vector Forwarding Vector
Offered Vector Offered Vector
Nonconforming Nonconforming
Network-layer Traffic Control Mechanisms
3.2.3 Nonconforming Packet 3.2.3 Nonconforming Packet
Definition: Definition:
Packets that do not lie within specific rate, delay, or Packets that do not lie within specific rate, delay, or
jitter bounds. jitter bounds.
Discussion: Discussion:
A DUT/SUT may be configured to allow a given traffic class to A DUT/SUT may be configured to allow a given traffic class to
consume a given amount of bandwidth, or to fall within consume a given amount of bandwidth, or to fall within
skipping to change at page 9, line 51 skipping to change at page 10, line 5
instrument. instrument.
Forwarding Delay differs from latency [Br91] and one-way Forwarding Delay differs from latency [Br91] and one-way
delay [Al99] in several key regards: delay [Al99] in several key regards:
1. Latency [Br91] assumes knowledge of whether the DUT/SUT 1. Latency [Br91] assumes knowledge of whether the DUT/SUT
uses "store and forward" or "bit forwarding" technology. uses "store and forward" or "bit forwarding" technology.
Forwarding Delay is the same metric, measured the same way, Forwarding Delay is the same metric, measured the same way,
regardless of the architecture of the DUT/SUT. regardless of the architecture of the DUT/SUT.
Network-layer Traffic Control Mechanisms
2. Forwarding Delay is a last-in, last-out (LILO) 2. Forwarding Delay is a last-in, last-out (LILO)
measurement, unlike the last-in, first-out method [Br91] or measurement, unlike the last-in, first-out method [Br91] or
the first-in, last-out method [Al99]. the first-in, last-out method [Al99].
Network-layer Traffic Control Mechanisms
The LILO method most closely simulates the way a network- The LILO method most closely simulates the way a network-
layer device actually processes an IP datagram. IP datagrams layer device actually processes an IP datagram. IP datagrams
are not passed up and down the stack unless they are are not passed up and down the stack unless they are
complete, and processing begins only once the last bit of the complete, and processing begins only once the last bit of the
IP datagram has been received. IP datagram has been received.
Further, the LILO method has an additive property, where the Further, the LILO method has an additive property, where the
sum of the parts MUST equal the whole. This is a key sum of the parts MUST equal the whole. This is a key
difference from [Br91] and [Al99]. For example, the delay difference from [Br91] and [Al99]. For example, the delay
added by two DUTs MUST equal the sum of the delay of the added by two DUTs MUST equal the sum of the delay of the
skipping to change at page 10, line 52 skipping to change at page 11, line 5
Note: Forwarding Delay SHOULD NOT be used as an absolute Note: Forwarding Delay SHOULD NOT be used as an absolute
indicator of DUT/SUT Forwarding Congestion. While Forwarding indicator of DUT/SUT Forwarding Congestion. While Forwarding
Delay may rise when offered load nears or exceeds channel Delay may rise when offered load nears or exceeds channel
capacity, there is no universal point at which Forwarding capacity, there is no universal point at which Forwarding
Delay can be said to indicate the presence or absence of Delay can be said to indicate the presence or absence of
Forwarding Congestion. Forwarding Congestion.
Measurement units: Measurement units:
Seconds. Seconds.
Network-layer Traffic Control Mechanisms
See Also: See Also:
Latency [Br91] Latency [Br91]
Latency [Al99] Latency [Al99]
One-way Delay [Br99] One-way Delay [Br99]
Network-layer Traffic Control Mechanisms
3.2.5 Jitter 3.2.5 Jitter
Definition: Definition:
The absolute value of the difference between the arrival The absolute value of the difference between the arrival
delay of two consecutive received packets belonging to the delay of two consecutive received packets belonging to the
same stream. same stream.
Discussion: Discussion:
The delay fluctuation between two consecutive received The delay fluctuation between two consecutive received
skipping to change at page 11, line 27 skipping to change at page 11, line 33
is the order the packets were received. is the order the packets were received.
Under loss, jitter can be measured between non-consecutive Under loss, jitter can be measured between non-consecutive
test sequence numbers. When Traffic Control Mechanisms are test sequence numbers. When Traffic Control Mechanisms are
losing packets, the Forwarding Delay may fluctuate as a losing packets, the Forwarding Delay may fluctuate as a
response. Jitter MUST be able to benchmark the delay response. Jitter MUST be able to benchmark the delay
variation with or with out loss. variation with or with out loss.
Jitter is related to the ipdv [De02] (IP Delay Variation) by Jitter is related to the ipdv [De02] (IP Delay Variation) by
taking the absolute value of the ipdv. The two metrics will taking the absolute value of the ipdv. The two metrics will
produce different mean values. _Mean Jitter_ will produce a produce different mean values. “Mean Jitter” will produce a
positive value, where the _mean ipdv_ is typically zero. positive value, where the “mean ipdv” is typically zero.
Measurement units: Measurement units:
Seconds Seconds
See Also: See Also:
Forwarding Delay Forwarding Delay
Jitter variation [Ja99] Jitter variation [Ja99]
ipdv [De02] ipdv [De02]
interarrival jitter [Sc96] interarrival jitter [Sc96]
skipping to change at page 11, line 51 skipping to change at page 12, line 5
Definition: Definition:
The vector(s) obtained when mechanisms used to support diff- The vector(s) obtained when mechanisms used to support diff-
serv or IP precedence are disabled. serv or IP precedence are disabled.
Discussion: Discussion:
Enabling diff-serv or IP precedence mechanisms may impose Enabling diff-serv or IP precedence mechanisms may impose
additional processing overhead for packets. This overhead additional processing overhead for packets. This overhead
may degrade performance even when traffic belonging to only may degrade performance even when traffic belonging to only
one class, the best-effort class, is offered to the device. one class, the best-effort class, is offered to the device.
Network-layer Traffic Control Mechanisms
Measurements with "undifferentiated response" should be made Measurements with "undifferentiated response" should be made
to establish a baseline. to establish a baseline.
The vector(s) obtained with DSCP or IP precedence enabled can The vector(s) obtained with DSCP or IP precedence enabled can
be compared to the undifferentiated response to determine the be compared to the undifferentiated response to determine the
effect of differentiating traffic. effect of differentiating traffic.
Network-layer Traffic Control Mechanisms
Measurement units: Measurement units:
n/a n/a
3.3 Sequence Tracking 3.3 Sequence Tracking
3.3.1 In-sequence Packet 3.3.1 In-sequence Packet
Definition: Definition:
A received packet with the expected Test Sequence number. A received packet with the expected Test Sequence number.
Discussion: Discussion:
In-sequence is done on a stream level. As packets are In-sequence is done on a stream level. As packets are
received on a stream, each packet's Test Sequence number is received on a stream, each packets Test Sequence number is
compared with the previous packet. Only packets that match compared with the previous packet. Only packets that match
the expected Test Sequence number are considered in-sequence. the expected Test Sequence number are considered in-sequence.
Packets that do not match the expected Test Sequence number Packets that do not match the expected Test Sequence number
are counted as "not in-sequence" or out-of-sequence. Every are counted as "not in-sequence" or out-of-sequence. Every
packet that is received is either in-sequence or out-of- packet that is received is either in-sequence or out-of-
sequence. Subtracting the in-sequence from the received sequence. Subtracting the in-sequence from the received
packets (for that stream) can derive the out-of-sequence packets (for that stream) can derive the out-of-sequence
count. count.
skipping to change at page 12, line 46 skipping to change at page 13, line 5
See Also: See Also:
Stream Stream
Test Sequence number Test Sequence number
3.3.2 Out-of-order Packet 3.3.2 Out-of-order Packet
Definition: Definition:
A received packet with a Test Sequence number less than A received packet with a Test Sequence number less than
expected. expected.
Network-layer Traffic Control Mechanisms
Discussion: Discussion:
As a stream of packets enters a DUT/SUT, they include a As a stream of packets enters a DUT/SUT, they include a
Stream Test Sequence number indicating the order the packets Stream Test Sequence number indicating the order the packets
were sent to the DUT/SUT. On exiting the DUT/SUT, these were sent to the DUT/SUT. On exiting the DUT/SUT, these
packets may arrive in a different order. Each packet that packets may arrive in a different order. Each packet that
was re-ordered is counted as an Out-of-order Packet. was re-ordered is counted as an Out-of-order Packet.
Network-layer Traffic Control Mechanisms
Certain streaming protocol (such as TCP) require the packets Certain streaming protocol (such as TCP) require the packets
to be in a certain order. Packets outside this are dropped to be in a certain order. Packets outside this are dropped
by the streaming protocols even though there were properly by the streaming protocols even though there were properly
received by the IP layer. The type of reordering tolerated received by the IP layer. The type of reordering tolerated
by a streaming protocol varies from protocol to protocol, and by a streaming protocol varies from protocol to protocol, and
also by implementation. also by implementation.
Out-of-order Packet count is based on the worst case Out-of-order Packet count is based on the worst case
streaming protocol. It allows for no reordering. streaming protocol. It allows for no reordering.
skipping to change at page 13, line 47 skipping to change at page 14, line 5
successfully transmitted out an egress interface more than successfully transmitted out an egress interface more than
once. The egress interface has previously forwarded this once. The egress interface has previously forwarded this
packet. packet.
A Duplicate Packet SHOULD be a bit for bit copy of an already A Duplicate Packet SHOULD be a bit for bit copy of an already
transmitted packet (including Test Sequence number). If the transmitted packet (including Test Sequence number). If the
Duplicate Packet traversed different paths through the Duplicate Packet traversed different paths through the
DUT/SUT, some fields (such as TTL or checksum) may have DUT/SUT, some fields (such as TTL or checksum) may have
changed. changed.
Network-layer Traffic Control Mechanisms
A multicast packet is not a Duplicate Packet by definition. A multicast packet is not a Duplicate Packet by definition.
For a given IP multicast group, a DUT/SUT SHOULD forward a For a given IP multicast group, a DUT/SUT SHOULD forward a
packet once on a given egress interface provided the path to packet once on a given egress interface provided the path to
one or more multicast receivers is through that interface. one or more multicast receivers is through that interface.
Several egress interfaces will transmit the same packet, but Several egress interfaces will transmit the same packet, but
only once per interface. only once per interface.
To detect a Duplicate Packet, each offered packet to the To detect a Duplicate Packet, each offered packet to the
DUT/SUT MUST contain a unique packet-by-packet identifier. DUT/SUT MUST contain a unique packet-by-packet identifier.
Network-layer Traffic Control Mechanisms
Measurement units: Measurement units:
Packet count Packet count
See Also: See Also:
Stream Stream
Test Sequence number Test Sequence number
3.3.4 Stream 3.3.4 Stream
Definition: Definition:
A group of packets tracked as a single entity by the traffic A group of packets tracked as a single entity by the traffic
receiver. A stream may share a common content such as type receiver. A stream may share a common content such as type
(IP, UDP), packet size, or payload. (IP, UDP), packet size, or payload.
Discussion: Discussion:
Streams are tracked by test sequence number or "unique Streams are tracked by test sequence number or "unique
signature field" [Ma00]. Streams define how individual signature field" [Ma00]. Streams define how individual
packets' statistic are grouped together to form an packets statistic are grouped together to form an
intelligible summary. intelligible summary.
Common stream groupings would be by egress interface, Common stream groupings would be by egress interface,
destination address, source address, DSCP, or IP precedence. destination address, source address, DSCP, or IP precedence.
A stream using test sequence numbers can track the ordering A stream using test sequence numbers can track the ordering
of packets as they transverse the DUT/SUT. of packets as they transverse the DUT/SUT.
Streams are not restricted to a pair of source and Streams are not restricted to a pair of source and
destination interfaces as long as all packets are tracked as destination interfaces as long as all packets are tracked as
a single entity. A mulitcast stream can be forward to a single entity. A mulitcast stream can be forward to
multiple destination interfaces. multiple destination interfaces.
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
Flow Flow
Microflow [Ni98] Microflow [Ni98]
Test sequence number Test sequence number
Network-layer Traffic Control Mechanisms
3.3.5 Test Sequence number 3.3.5 Test Sequence number
Definition: Definition:
A field in the IP payload portion of the packet that is used A field in the IP payload portion of the packet that is used
to verify the order of the packets on the egress of the to verify the order of the packets on the egress of the
DUT/SUT. DUT/SUT.
Network-layer Traffic Control Mechanisms
Discussion: Discussion:
The traffic generator sets the test sequence number value and The traffic generator sets the test sequence number value and
the traffic receiver checks the value upon receipt of the the traffic receiver checks the value upon receipt of the
packet. The traffic generator changes the value on each packet. The traffic generator changes the value on each
packet transmitted based on an algorithm agreed to by the packet transmitted based on an algorithm agreed to by the
traffic receiver. traffic receiver.
The traffic receiver keeps track of the sequence numbers on a The traffic receiver keeps track of the sequence numbers on a
per stream basis. In addition to number of received packets, per stream basis. In addition to number of received packets,
the traffic receiver may also report number of in-sequence the traffic receiver may also report number of in-sequence
skipping to change at page 21, line 35 skipping to change at page 21, line 35
Output Vectors Output Vectors
Expected Loss Vector Expected Loss Vector
Expected Sequence Vector Expected Sequence Vector
Expected Forwarding Vector Expected Forwarding Vector
Expected Jitter Vector Expected Jitter Vector
3.4.3.8 Expected Instantaneous Jitter Vector 3.4.3.8 Expected Instantaneous Jitter Vector
Definition: Definition:
A vector describing the expected jitter between two A vector describing the expected jitter between two
consecutive packets' arrival times having a specific DSCP or consecutive packets arrival times having a specific DSCP or
IP precedence value. The value is dependent on the set of IP precedence value. The value is dependent on the set of
offered vectors and configuration of the DUT. offered vectors and configuration of the DUT.
Discussion: Discussion:
Instantaneous Jitter is the absolute value of the difference Instantaneous Jitter is the absolute value of the difference
between the delay measurement of two packets belonging to the between the delay measurement of two packets belonging to the
same stream. same stream.
The delay fluctuation between two consecutive packets in a The delay fluctuation between two consecutive packets in a
stream is reported as the "Instantaneous Jitter". stream is reported as the "Instantaneous Jitter".
skipping to change at page 33, line 4 skipping to change at page 32, line 48
[Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984. RFC 896, January 1984.
[Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC 2481, Explicit Congestion Notification (ECN) to IP", RFC 2481,
January 1999. January 1999.
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996 RFC 1889, January 1996
[Sh48] C. E. Shannon, "A mathematical theory of communication",
Bell System Technical Journal, vol. 27, pp. 379-423 and
623-656, July and October 1948
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
8. Authors' Addresses 8. Authors' Addresses
Jerry Perser Jerry Perser
Spirent Communications Spirent Communications
26750 Agoura Road 26750 Agoura Road
Calabasas, CA 91302 Calabasas, CA 91302
USA USA
skipping to change at page 33, line 45 skipping to change at page 33, line 45
Shobha Erramilli Shobha Erramilli
QNetworx Inc QNetworx Inc
1119 Campus Drive West 1119 Campus Drive West
Morganville, NJ 07751 Morganville, NJ 07751
USA USA
Phone: Phone:
EMail: shobha@qnetworx.com EMail: shobha@qnetworx.com
Scott Poretsky Scott Poretsky
Avici Systems Quarry Technologies
101 Billerica Ave_Building #6 New England Executive Park
N. Billerica, MA 01862 Burlington, MA 01803
USA USA
Phone: + 1 978 964 2287 Phone: + 1 781 395 5090
EMail: sporetsky@avici.com EMail: sporetsky@quarrytech.com
Network-layer Traffic Control Mechanisms Network-layer Traffic Control Mechanisms
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Copyright (C) The Internet Society (2003). All Rights
Reserved. Reserved.
This document and translations of it may be copied and This document and translations of it may be copied and
furnished to others, and derivative works that comment on or furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be otherwise explain it or assist in its implementation may be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/