draft-ietf-avtext-rtp-duplication-03.txt | draft-ietf-avtext-rtp-duplication-04.txt | |||
---|---|---|---|---|
AVTEXT A. Begen | AVTEXT A. Begen | |||
Internet-Draft Cisco | Internet-Draft Cisco | |||
Intended status: Standards Track C. Perkins | Intended status: Standards Track C. Perkins | |||
Expires: March 24, 2014 University of Glasgow | Expires: April 05, 2014 University of Glasgow | |||
September 20, 2013 | October 02, 2013 | |||
Duplicating RTP Streams | Duplicating RTP Streams | |||
draft-ietf-avtext-rtp-duplication-03 | draft-ietf-avtext-rtp-duplication-04 | |||
Abstract | Abstract | |||
Packet loss is undesirable for real-time multimedia sessions, but can | Packet loss is undesirable for real-time multimedia sessions, but can | |||
occur due to congestion, or other unplanned network outages. This is | occur due to congestion, or other unplanned network outages. This is | |||
especially true for IP multicast networks, where packet loss patterns | especially true for IP multicast networks, where packet loss patterns | |||
can vary greatly between receivers. One technique that can be used | can vary greatly between receivers. One technique that can be used | |||
to recover from packet loss without incurring unbounded delay for all | to recover from packet loss without incurring unbounded delay for all | |||
the receivers is to duplicate the packets and send them in separate | the receivers is to duplicate the packets and send them in separate | |||
redundant streams. This document explains how Real-time Transport | redundant streams. This document explains how Real-time Transport | |||
skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
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 March 24, 2014. | This Internet-Draft will expire on April 05, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 18 ¶ | skipping to change at page 2, line 18 ¶ | |||
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. Terminology and Requirements Notation . . . . . . . . . . . . 3 | 2. Terminology and Requirements Notation . . . . . . . . . . . . 3 | |||
3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3 | 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3 | |||
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3 | 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3 | |||
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4 | 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4 | |||
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4 | 3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4 | |||
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 5 | 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6 | ||||
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 | 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6 | 4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6 | |||
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7 | 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8 | |||
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7 | 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8 | 5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8 | |||
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 8 | 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 7. Congestion Control Considerations . . . . . . . . . . . . . . 9 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 9 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | 11.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today | The Real-time Transport Protocol (RTP) [RFC3550] is widely used today | |||
for delivering IPTV traffic, and other real-time multimedia sessions. | for delivering IPTV traffic, and other real-time multimedia sessions. | |||
Many of these applications support very large numbers of receivers, | Many of these applications support very large numbers of receivers, | |||
and rely on intra-domain UDP/IP multicast for efficient distribution | and rely on intra-domain UDP/IP multicast for efficient distribution | |||
of traffic within the network. | of traffic within the network. | |||
While this combination has proved successful, there does exist a | While this combination has proved successful, there does exist a | |||
skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 10 ¶ | |||
person accidentally cutting the wrong fiber. Since UDP/IP flows do | person accidentally cutting the wrong fiber. Since UDP/IP flows do | |||
not provide any means for detecting loss and retransmitting packets, | not provide any means for detecting loss and retransmitting packets, | |||
it leaves up to the RTP layer and the applications to detect, and | it leaves up to the RTP layer and the applications to detect, and | |||
recover from, packet loss. | recover from, packet loss. | |||
One technique to recover from packet loss without incurring unbounded | One technique to recover from packet loss without incurring unbounded | |||
delay for all the receivers is to duplicate the packets and send them | delay for all the receivers is to duplicate the packets and send them | |||
in separate redundant streams. Variations on this idea have been | in separate redundant streams. Variations on this idea have been | |||
implemented and deployed today [IC2011]. However, duplication of RTP | implemented and deployed today [IC2011]. However, duplication of RTP | |||
streams without breaking the RTP and RTCP functionality has not been | streams without breaking the RTP and RTCP functionality has not been | |||
documented properly. This document explains how duplication can be | documented properly. This document discusses the most common use | |||
achieved for RTP streams. | cases and explains how duplication can be achieved for RTP streams in | |||
such use cases to address the immediate market needs. In the future, | ||||
if there will be a different use case, which is not covered by this | ||||
document, a new specification that explains how RTP duplication | ||||
should be done in such a scenario may be needed. | ||||
Stream duplication offers a simple way to protect media flows from | Stream duplication offers a simple way to protect media flows from | |||
packet loss. It has a comparatively high bandwidth overhead, since | packet loss. It has a comparatively high bandwidth overhead, since | |||
everything is sent twice, but with a low processing overhead. It is | everything is sent twice, but with a low processing overhead. It is | |||
also very predictable in its overheads. Alternative approaches may | also very predictable in its overheads. Alternative approaches, for | |||
be suitable in some cases, for example retransmission-based recovery | example, retransmission-based recovery [RFC4588] or Forward Error | |||
[RFC4588] or Forward Error Correction [RFC6363]. | Correction [RFC6363], may be suitable in some other cases. | |||
2. Terminology and Requirements Notation | 2. Terminology and Requirements Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
[RFC2119]. | [RFC2119]. | |||
3. Dual Streaming Use Cases | 3. Dual Streaming Use Cases | |||
skipping to change at page 3, line 40 ¶ | skipping to change at page 3, line 44 ¶ | |||
redundant RTP streams (the original plus its duplicate) of the same | redundant RTP streams (the original plus its duplicate) of the same | |||
content, with each stream capable of supporting the playback when | content, with each stream capable of supporting the playback when | |||
there is no packet loss. Therefore, adding an additional RTP stream | there is no packet loss. Therefore, adding an additional RTP stream | |||
provides a protection against packet loss. The level of protection | provides a protection against packet loss. The level of protection | |||
depends on how the packets are sent and transmitted inside the | depends on how the packets are sent and transmitted inside the | |||
network. | network. | |||
It is important to note that dual streaming can easily be extended to | It is important to note that dual streaming can easily be extended to | |||
support cases when more than two streams are desired. However, using | support cases when more than two streams are desired. However, using | |||
three or more streams is rare in practice, due to the high overhead | three or more streams is rare in practice, due to the high overhead | |||
that it incurs. | that it incurs and the little additional protection it provides. | |||
3.1. Temporal Redundancy | 3.1. Temporal Redundancy | |||
From a routing perspective, two streams are considered identical if | From a routing perspective, two streams are considered identical if | |||
the following two IP header fields are the same, since they will be | the following two IP header fields are the same, since they will be | |||
both routed over the same path: | both routed over the same path: | |||
o IP Source Address | o IP Source Address | |||
o IP Destination Address | o IP Destination Address | |||
Two routing-plane identical RTP streams might carry the same payload, | Two routing-plane identical RTP streams might carry the same payload, | |||
but can use different Synchronization Sources (SSRC) to differentiate | but can use different Synchronization Sources (SSRC) to differentiate | |||
the RTP packets belonging to each stream. In the context of dual RTP | the RTP packets belonging to each stream. In the context of dual RTP | |||
streaming, we assume that the sender duplicates the RTP packets and | streaming, we assume that the sender duplicates the RTP packets and | |||
sends them in separate RTP streams, each with a unique SSRC. All the | sends them in separate RTP streams, each with a unique SSRC. All the | |||
redundant streams are transmitted in the same RTP session. | redundant streams are transmitted in the same RTP session. | |||
For example, one main stream and its duplicate stream can be sent to | For example, one main stream and its duplicate stream can be sent to | |||
the same IP destination address and UDP destination port with a | the same IP destination address and UDP destination port with a | |||
certain delay between them [I-D.ietf-mmusic-delayed-duplication]. | certain delay between them [I-D.ietf-mmusic-delayed-duplication]. | |||
skipping to change at page 5, line 39 ¶ | skipping to change at page 5, line 41 ¶ | |||
sort (e.g., RTP sequence numbers). | sort (e.g., RTP sequence numbers). | |||
To summarize, dual streaming allows an application and a network to | To summarize, dual streaming allows an application and a network to | |||
work together to provide a near zero-loss transport with a bounded or | work together to provide a near zero-loss transport with a bounded or | |||
minimum delay. The additional advantage includes a predictable | minimum delay. The additional advantage includes a predictable | |||
bandwidth overhead that is proportional to the minimum bandwidth | bandwidth overhead that is proportional to the minimum bandwidth | |||
needed for the multimedia session, but independent of the number of | needed for the multimedia session, but independent of the number of | |||
receivers experiencing a packet loss and requesting a retransmission. | receivers experiencing a packet loss and requesting a retransmission. | |||
For a survey and comparison of similar approaches, refer to [IC2011]. | For a survey and comparison of similar approaches, refer to [IC2011]. | |||
3.4. Requirements | ||||
One of the following conditions is REQUIRED to hold in applications | ||||
using this specification: | ||||
o The original and duplicate RTP streams are carried (with their own | ||||
SSRCs) in the same "m" line (There could be other RTP streams | ||||
listed in the same "m" line) | ||||
o The original and duplicate RTP streams are carried in separate "m" | ||||
lines and there is no other RTP stream listed in either "m" line. | ||||
When the original and duplicate RTP streams are carried in separate | ||||
"m" lines in an SDP description and if the SDP description has one or | ||||
more other RTP streams listed in either "m" line, duplication | ||||
grouping is not trivial and further signaling will be needed, which | ||||
is left for future standardization. | ||||
4. Use of RTP and RTCP with Temporal Redundancy | 4. Use of RTP and RTCP with Temporal Redundancy | |||
To achieve temporal redundancy, the main and duplicate RTP streams | To achieve temporal redundancy, the main and duplicate RTP streams | |||
SHOULD be sent using the sample 5-tuple of transport protocol, source | SHOULD be sent using the sample 5-tuple of transport protocol, source | |||
and destination IP addresses, and source and destination transport | and destination IP addresses, and source and destination transport | |||
ports. Due to the possible presence of network address and port | ports. Due to the possible presence of network address and port | |||
translation (NAPT) devices, load balancers, or other middleboxes, use | translation (NAPT) devices, load balancers, or other middleboxes, use | |||
of anything other than an identical 5-tuple might also cause spatial | of anything other than an identical 5-tuple might also cause spatial | |||
redundancy (which might introduce an additional delay due to the | redundancy (which might introduce an additional delay due to the | |||
delta between the path delays), and so is NOT RECOMMENDED unless the | delta between the path delays), and so is NOT RECOMMENDED unless the | |||
skipping to change at page 8, line 46 ¶ | skipping to change at page 9, line 21 ¶ | |||
c=IN IP4 233.252.0.2/127 | c=IN IP4 233.252.0.2/127 | |||
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 | a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 | |||
a=rtpmap:101 MP2T/90000 | a=rtpmap:101 MP2T/90000 | |||
a=mid:S1b | a=mid:S1b | |||
6. Use of RTP and RTCP with Temporal and Spatial Redundancy | 6. Use of RTP and RTCP with Temporal and Spatial Redundancy | |||
This uses the same RTP/RTCP mechanisms from Sections Section 4 and | This uses the same RTP/RTCP mechanisms from Sections Section 4 and | |||
Section 5, plus a combination of both sets of signaling. | Section 5, plus a combination of both sets of signaling. | |||
7. Security Considerations | 7. Congestion Control Considerations | |||
Duplicating RTP streams has several considerations in the context of | ||||
congestion control. First of all, RTP duplication MUST NOT be used | ||||
in cases where the primary cause of packet loss is congestion since | ||||
duplication can make congestion only worse. Furthermore, RTP | ||||
duplication SHOULD NOT be used where there is a risk of congestion | ||||
upon duplicating an RTP stream. Duplication is RECOMMENDED only to | ||||
be used for protection against network outages due to a temporary | ||||
link or network element failure and where it is known that there is | ||||
sufficient network capacity to carry the duplicated traffic. The | ||||
capacity requirement constrains the use of duplication to managed | ||||
networks, and makes it unsuitable for use on unmanaged public | ||||
networks. | ||||
It is essential that the nodes responsible for the duplication and | ||||
de-duplication are aware of the original stream's requirements and | ||||
the available capacity inside the network. If there is an adaptation | ||||
capability for the original stream, these nodes have to assume the | ||||
same adaptation capability for the duplicated stream, too. For | ||||
example, if the source doubles the bitrate for the original stream, | ||||
the bitrate of the duplicate stream will also be doubled. | ||||
Depending on where de-duplication takes place, there could be | ||||
different scenarios. When the duplication and de-duplication takes | ||||
place inside the network before the ultimate end-points that will | ||||
consume the RTP media, the whole process is transparent to these end- | ||||
points. Thus, these end-points will apply any congestion control, if | ||||
applicable, on the de-duplicated RTP stream. This output stream will | ||||
have less losses than either of the original and duplicated stream, | ||||
and the end-point will make congestion control decisions accordingly. | ||||
However, if de-duplication takes place at the ultimate end-point, | ||||
this end-point MUST consider the aggregate of the original and | ||||
duplicated RTP stream in any congestion control it wants to apply. | ||||
The end-point will observe the losses in each stream separately, and | ||||
this information can be used to fine-tune the duplication process. | ||||
For example, the duplication interval can be adjusted based on the | ||||
duration of a common packet loss in both streams. | ||||
8. Security Considerations | ||||
The security considerations of [RFC3550], | The security considerations of [RFC3550], | |||
[I-D.ietf-mmusic-delayed-duplication], and | [I-D.ietf-mmusic-delayed-duplication], | |||
[I-D.ietf-mmusic-duplication-grouping] apply. | [I-D.ietf-mmusic-duplication-grouping], and any RTP profiles and | |||
payload formats in use apply. | ||||
Duplication can be performed end-to-end, with the media sender | ||||
generating a duplicate RTP stream, and the receiver(s) performing de- | ||||
duplication. In such cases, if the original media stream is to be | ||||
authenticated (e.g., using SRTP [RFC3711]) then the duplicate stream | ||||
also needs to be authenticated, and duplicate packets that fail the | ||||
authentication check need to be discarded. | ||||
Stream duplication and de-duplication can also be performed by in- | ||||
network middleboxes. Such middleboxes will need to rewrite the RTP | ||||
SSRC such that the RTP packets in the duplicate stream have a | ||||
different SSRC to the original stream, and will need to generate and | ||||
respond to RTCP packets corresponding to the duplicate stream. This | ||||
sort of in-network duplication service has the potential to act as an | ||||
amplifier for denial-of-service attacks if the attacker can cause | ||||
attack traffic to be duplicated. To prevent this, middleboxes | ||||
providing the duplication service need to authenticate the traffic to | ||||
be duplicated as being from a legitimate source, for example using | ||||
the secure RTP (SRTP) profile [RFC3711]. This requires the middlebox | ||||
to be part of the security context of the media session being | ||||
duplicated, so it has access to the necessary keying material for | ||||
authentication. To do this, the middlebox will need to be privy to | ||||
the session set-up signalling. Details of how that is done will | ||||
depend on the type of signalling used (SIP, RTSP, WebRTC, etc.), and | ||||
is not specified here. | ||||
Similarly, to prevent packet injection attacks, a de-duplication | ||||
middlebox needs to authenticate original and duplicate streams, and | ||||
ought not use non-authenticated packets that are received. Again, | ||||
this requires the middlebox to be part of the security context, and | ||||
have access to the appropriate signalling and keying material. | ||||
Stream de-duplication can be done by an in-network middlebox, | ||||
rewriting the SSRC as appropriate. If the Secure RTP (SRTP) profile | ||||
[RFC3711] is used to authenticate RTP packets, such rewriting is not | ||||
possible without breaking the authentication, unless the de- | ||||
duplication middlebox is trusted to re-authenticate the packets. | ||||
This would require additional signaling that is not specified here. | ||||
The use of the encryption features of SRTP does not affect stream de- | The use of the encryption features of SRTP does not affect stream de- | |||
duplication middleboxes, since the RTP headers are sent in the clear. | duplication middleboxes, since the RTP headers are sent in the clear. | |||
8. IANA Considerations | 9. IANA Considerations | |||
No IANA actions are required. | No IANA actions are required. | |||
9. Acknowledgments | 10. Acknowledgments | |||
Thanks to Magnus Westerlund for his suggestions. | Thanks to Magnus Westerlund for his suggestions. | |||
10. References | 11. References | |||
10.1. Normative References | 11.1. Normative References | |||
[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, July 2003. | Applications", STD 64, RFC 3550, July 2003. | |||
[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, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[I-D.ietf-mmusic-delayed-duplication] | [I-D.ietf-mmusic-delayed-duplication] | |||
Begen, A., Cai, Y., and H. Ou, "Delayed Duplication | Begen, A., Cai, Y., and H. Ou, "Delayed Duplication | |||
skipping to change at page 9, line 49 ¶ | skipping to change at page 11, line 43 ¶ | |||
[I-D.ietf-mmusic-duplication-grouping] | [I-D.ietf-mmusic-duplication-grouping] | |||
Begen, A., Cai, Y., and H. Ou, "Duplication Grouping | Begen, A., Cai, Y., and H. Ou, "Duplication Grouping | |||
Semantics in the Session Description Protocol", draft- | Semantics in the Session Description Protocol", draft- | |||
ietf-mmusic-duplication-grouping-03 (work in progress), | ietf-mmusic-duplication-grouping-03 (work in progress), | |||
July 2013. | July 2013. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, March 2004. | RFC 3711, March 2004. | |||
10.2. Informative References | 11.2. Informative References | |||
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of | [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of | |||
Streaming Media", RFC 2354, June 1998. | Streaming Media", RFC 2354, June 1998. | |||
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. | |||
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | Hakenberg, "RTP Retransmission Payload Format", RFC 4588, | |||
July 2006. | July 2006. | |||
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error | [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error | |||
Correction (FEC) Framework", RFC 6363, October 2011. | Correction (FEC) Framework", RFC 6363, October 2011. | |||
skipping to change at line 457 ¶ | skipping to change at page 12, line 29 ¶ | |||
Email: abegen@cisco.com | Email: abegen@cisco.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
URI: http://orcid.org/0000-0002-3404-8964 | ||||
End of changes. 21 change blocks. | ||||
36 lines changed or deleted | 125 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |