draft-ietf-avtcore-cc-feedback-message-06.txt | draft-ietf-avtcore-cc-feedback-message-07.txt | |||
---|---|---|---|---|
IETF RMCAT Working Group Z. Sarker | IETF RMCAT Working Group Z. Sarker | |||
Internet-Draft Ericsson AB | Internet-Draft Ericsson AB | |||
Intended status: Standards Track C. Perkins | Intended status: Standards Track C. Perkins | |||
Expires: September 10, 2020 University of Glasgow | Expires: December 12, 2020 University of Glasgow | |||
V. Singh | V. Singh | |||
callstats.io | callstats.io | |||
M. Ramalho | M. Ramalho | |||
March 9, 2020 | June 10, 2020 | |||
RTP Control Protocol (RTCP) Feedback for Congestion Control | RTP Control Protocol (RTCP) Feedback for Congestion Control | |||
draft-ietf-avtcore-cc-feedback-message-06 | draft-ietf-avtcore-cc-feedback-message-07 | |||
Abstract | Abstract | |||
This document describes an RTCP feedback message intended to enable | This document describes an RTCP feedback message intended to enable | |||
congestion control for interactive real-time traffic using RTP. The | congestion control for interactive real-time traffic using RTP. The | |||
feedback message is designed for use with a sender-based congestion | feedback message is designed for use with a sender-based congestion | |||
control algorithm, in which the receiver of an RTP flow sends RTCP | control algorithm, in which the receiver of an RTP flow sends RTCP | |||
feedback packets to the sender containing the information the sender | feedback packets to the sender containing the information the sender | |||
needs to perform congestion control. | needs to perform congestion control. | |||
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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 10, 2020. | This Internet-Draft will expire on December 12, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://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 22 ¶ | skipping to change at page 2, line 22 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 | 3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 | |||
3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 | 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 | |||
4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 | 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 | |||
5. Response to Loss of Feedback Packets . . . . . . . . . . . . 7 | 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 7 | |||
6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8 | 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 13 | 12.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
1. Introduction | 1. Introduction | |||
For interactive real-time traffic, such as video conferencing flows, | For interactive real-time traffic, such as video conferencing flows, | |||
the typical protocol choice is the Real-time Transport Protocol (RTP) | the typical protocol choice is the Real-time Transport Protocol (RTP) | |||
running over the User Datagram Protocol (UDP). RTP does not provide | running over the User Datagram Protocol (UDP). RTP does not provide | |||
any guarantee of Quality of Service (QoS), reliability, or timely | any guarantee of Quality of Service (QoS), reliability, or timely | |||
delivery, and expects the underlying transport protocol to do so. | delivery, and expects the underlying transport protocol to do so. | |||
skipping to change at page 3, line 4 ¶ | skipping to change at page 3, line 4 ¶ | |||
have developed proprietary RTCP messages that convey only those | have developed proprietary RTCP messages that convey only those | |||
parameters needed for their respective designs. As a direct result, | parameters needed for their respective designs. As a direct result, | |||
the different congestion control (i.e., rate adaptation) designs are | the different congestion control (i.e., rate adaptation) designs are | |||
not interoperable. To enable algorithm evolution as well as | not interoperable. To enable algorithm evolution as well as | |||
interoperability across designs (e.g., different rate adaptation | interoperability across designs (e.g., different rate adaptation | |||
algorithms), it is highly desirable to have generic congestion | algorithms), it is highly desirable to have generic congestion | |||
control feedback format. | control feedback format. | |||
To help achieve interoperability for unicast RTP congestion control, | To help achieve interoperability for unicast RTP congestion control, | |||
this memo proposes a common RTCP feedback packet format that can be | this memo proposes a common RTCP feedback packet format that can be | |||
used by NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google | used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control | |||
Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck | [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and | |||
Detection [RFC8382], and hopefully also by future RTP congestion | hopefully also by future RTP congestion control algorithms. | |||
control algorithms. | ||||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
In addition the terminology defined in [RFC3550], [RFC3551], | In addition the terminology defined in [RFC3550], [RFC3551], | |||
[RFC3611], [RFC4585], and [RFC5506] applies. | [RFC3611], [RFC4585], and [RFC5506] applies. | |||
3. RTCP Feedback for Congestion Control | 3. RTCP Feedback for Congestion Control | |||
Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], | Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google | |||
Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck | Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck | |||
Detection [RFC8382], the following per-RTP packet congestion control | Detection [RFC8382], the following per-RTP packet congestion control | |||
feedback information has been determined to be necessary: | feedback information has been determined to be necessary: | |||
o RTP sequence number: The receiver of an RTP flow needs to feedback | o RTP sequence number: The receiver of an RTP flow needs to feedback | |||
the sequence numbers of the received RTP packets to the sender, so | the sequence numbers of the received RTP packets to the sender, so | |||
the sender can determine which packets were received and which | the sender can determine which packets were received and which | |||
were lost. Packet loss is used as an indication of congestion by | were lost. Packet loss is used as an indication of congestion by | |||
many congestion control algorithms. | many congestion control algorithms. | |||
o Packet Arrival Time: The receiver of an RTP flow needs to feedback | o Packet Arrival Time: The receiver of an RTP flow needs to feedback | |||
skipping to change at page 6, line 37 ¶ | skipping to change at page 6, line 37 ¶ | |||
an RTP packet was reported as received in one report, that packet | an RTP packet was reported as received in one report, that packet | |||
MUST also be reported as received in any overlapping reports sent | MUST also be reported as received in any overlapping reports sent | |||
later that cover its sequence number range. | later that cover its sequence number range. | |||
RTCP congestion control feedback packets can be large if they are | RTCP congestion control feedback packets can be large if they are | |||
sent infrequently relative to the number of RTP data packets. If an | sent infrequently relative to the number of RTP data packets. If an | |||
RTCP congestion control feedback packet is too large to fit within | RTCP congestion control feedback packet is too large to fit within | |||
the path MTU, its sender SHOULD split it into multiple feedback | the path MTU, its sender SHOULD split it into multiple feedback | |||
packets. The RTCP reporting interval SHOULD be chosen such that | packets. The RTCP reporting interval SHOULD be chosen such that | |||
feedback packets are sent often enough that they are small enough to | feedback packets are sent often enough that they are small enough to | |||
fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] provides | fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] discusses | |||
guidance on how to choose the reporting interval). | how to choose the reporting interval; specifications for RTP | |||
congestion control algorithms can also provide guidance). | ||||
If duplicate copies of a particular RTP packet are received, then the | If duplicate copies of a particular RTP packet are received, then the | |||
arrival time of the first copy to arrive MUST be reported. If any of | arrival time of the first copy to arrive MUST be reported. If any of | |||
the copies of the duplicated packet are ECN-CE marked, then an ECN-CE | the copies of the duplicated packet are ECN-CE marked, then an ECN-CE | |||
mark MUST be reported that for packet; otherwise the ECN mark of the | mark MUST be reported that for packet; otherwise the ECN mark of the | |||
first copy to arrive is reported. | first copy to arrive is reported. | |||
If no packets are received from an SSRC in a reporting interval, a | If no packets are received from an SSRC in a reporting interval, a | |||
report block MAY be sent with begin_seq set to the highest sequence | report block MAY be sent with begin_seq set to the highest sequence | |||
number previously received from that SSRC and num_reports set to zero | number previously received from that SSRC and num_reports set to zero | |||
skipping to change at page 7, line 27 ¶ | skipping to change at page 7, line 28 ¶ | |||
this trade-off, suggests desirable RTCP feedback rates, and provides | this trade-off, suggests desirable RTCP feedback rates, and provides | |||
guidance on how to configure the RTCP bandwidth fraction, etc., to | guidance on how to configure the RTCP bandwidth fraction, etc., to | |||
make appropriate use of the reporting block described in this memo. | make appropriate use of the reporting block described in this memo. | |||
Specifications for RTP congestion control algorithms can also provide | Specifications for RTP congestion control algorithms can also provide | |||
guidance. | guidance. | |||
It is generally understood that congestion control algorithms work | It is generally understood that congestion control algorithms work | |||
better with more frequent feedback. However, RTCP bandwidth and | better with more frequent feedback. However, RTCP bandwidth and | |||
transmission rules put some upper limits on how frequently the RTCP | transmission rules put some upper limits on how frequently the RTCP | |||
feedback messages can be sent from an RTP receiver to the RTP sender. | feedback messages can be sent from an RTP receiver to the RTP sender. | |||
It has been shown [I-D.ietf-rmcat-rtp-cc-feedback] that in many cases | In many cases, sending feedback once per frame is an upper bound | |||
sending feedback one per frame is an upper bound before the reporting | before the reporting overhead becomes excessive, although this will | |||
overhead becomes excessive, although this will depend on the media | depend on the media rate and more frequent feedback might be needed | |||
rate and more frequent feedback might be needed with high-rate media | with high-rate media flows [I-D.ietf-rmcat-rtp-cc-feedback]. | |||
flows. Analysis [feedback-requirements] has also shown that some | Analysis [feedback-requirements] has also shown that some candidate | |||
candidate congestion control algorithms can operate with less | congestion control algorithms can operate with less frequent | |||
frequent feedback, using a feedback interval range of 50-200ms. | feedback, using a feedback interval range of 50-200ms. Applications | |||
Applications need to negotiate an appropriate congestion control | need to negotiate an appropriate congestion control feedback interval | |||
feedback interval at session setup time, based on the choice of | at session setup time, based on the choice of congestion control | |||
congestion control algorithm, the expected media bit rate, and the | algorithm, the expected media bit rate, and the acceptable feedback | |||
acceptable feedback overhead. | overhead. | |||
5. Response to Loss of Feedback Packets | 5. Response to Loss of Feedback Packets | |||
Like all RTCP packets, RTCP congestion control feedback packets might | Like all RTCP packets, RTCP congestion control feedback packets might | |||
be lost. All RTP congestion control algorithms MUST specify how they | be lost. All RTP congestion control algorithms MUST specify how they | |||
respond to the loss of feedback packets. | respond to the loss of feedback packets. | |||
If only a single congestion control feedback packet is lost, an | If only a single congestion control feedback packet is lost, an | |||
appropriate response is to assume that the level of congestion has | appropriate response is to assume that the level of congestion has | |||
remained roughly the same as the previous report. However, if | remained roughly the same as the previous report. However, if | |||
skipping to change at page 11, line 24 ¶ | skipping to change at page 11, line 30 ¶ | |||
Value name: ccfb | Value name: ccfb | |||
Long name: Congestion Control Feedback | Long name: Congestion Control Feedback | |||
Usable with: ack | Usable with: ack | |||
Reference: (RFC number of this document, when published) | Reference: (RFC number of this document, when published) | |||
11. Security Considerations | 11. Security Considerations | |||
The security considerations of the RTP specification [RFC3550], the | The security considerations of the RTP specification [RFC3550], the | |||
applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), | applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), | |||
and the RTP congestion control algorithm that is in use (e.g., | and the RTP congestion control algorithm that is in use (e.g., | |||
[I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) | [RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply. | |||
apply. | ||||
A receiver that intentionally generates inaccurate RTCP congestion | A receiver that intentionally generates inaccurate RTCP congestion | |||
control feedback reports might be able trick the sender into sending | control feedback reports might be able trick the sender into sending | |||
at a greater rate than the path can support, thereby congesting the | at a greater rate than the path can support, thereby congesting the | |||
path. This will negatively impact the quality of experience of that | path. This will negatively impact the quality of experience of that | |||
receiver. Since RTP is an unreliable transport, a sender can | receiver. Since RTP is an unreliable transport, a sender can | |||
intentionally leave a gap in the RTP sequence number space without | intentionally leave a gap in the RTP sequence number space without | |||
causing harm, to check that the receiver is correctly reporting | causing harm, to check that the receiver is correctly reporting | |||
losses. | losses. | |||
skipping to change at page 12, line 10 ¶ | skipping to change at page 12, line 17 ¶ | |||
Holmberg, C., Alvestrand, H., and C. Jennings, | Holmberg, C., Alvestrand, H., and C. Jennings, | |||
"Negotiating Media Multiplexing Using the Session | "Negotiating Media Multiplexing Using the Session | |||
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- | |||
negotiation-54 (work in progress), December 2018. | negotiation-54 (work in progress), December 2018. | |||
[I-D.ietf-mmusic-sdp-mux-attributes] | [I-D.ietf-mmusic-sdp-mux-attributes] | |||
Nandakumar, S., "A Framework for SDP Attributes when | Nandakumar, S., "A Framework for SDP Attributes when | |||
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | |||
(work in progress), February 2018. | (work in progress), February 2018. | |||
[I-D.ietf-rmcat-rtp-cc-feedback] | ||||
Perkins, C., "RTP Control Protocol (RTCP) Feedback for | ||||
Congestion Control in Interactive Multimedia Conferences", | ||||
draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress), | ||||
November 2019. | ||||
[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, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
RFC 3168, DOI 10.17487/RFC3168, September 2001, | RFC 3168, DOI 10.17487/RFC3168, September 2001, | |||
<https://www.rfc-editor.org/info/rfc3168>. | <https://www.rfc-editor.org/info/rfc3168>. | |||
skipping to change at page 13, line 49 ¶ | skipping to change at page 14, line 5 ¶ | |||
for Transport-wide Congestion Control", draft-holmer- | for Transport-wide Congestion Control", draft-holmer- | |||
rmcat-transport-wide-cc-extensions-01 (work in progress), | rmcat-transport-wide-cc-extensions-01 (work in progress), | |||
October 2015. | October 2015. | |||
[I-D.ietf-rmcat-gcc] | [I-D.ietf-rmcat-gcc] | |||
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. | Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. | |||
Mascolo, "A Google Congestion Control Algorithm for Real- | Mascolo, "A Google Congestion Control Algorithm for Real- | |||
Time Communication", draft-ietf-rmcat-gcc-02 (work in | Time Communication", draft-ietf-rmcat-gcc-02 (work in | |||
progress), July 2016. | progress), July 2016. | |||
[I-D.ietf-rmcat-nada] | [I-D.ietf-rmcat-rtp-cc-feedback] | |||
Zhu, X., *, R., Ramalho, M., and S. Cruz, "NADA: A Unified | Perkins, C., "RTP Control Protocol (RTCP) Feedback for | |||
Congestion Control Scheme for Real-Time Media", draft- | Congestion Control in Interactive Multimedia Conferences", | |||
ietf-rmcat-nada-13 (work in progress), September 2019. | draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress), | |||
November 2019. | ||||
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, | |||
"Codec Control Messages in the RTP Audio-Visual Profile | "Codec Control Messages in the RTP Audio-Visual Profile | |||
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, | with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, | |||
February 2008, <https://www.rfc-editor.org/info/rfc5104>. | February 2008, <https://www.rfc-editor.org/info/rfc5104>. | |||
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol | [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol | |||
(RTCP) Extended Report (XR) Block for Delay Metric | (RTCP) Extended Report (XR) Block for Delay Metric | |||
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, | Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6843>. | <https://www.rfc-editor.org/info/rfc6843>. | |||
[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation | [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation | |||
for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December | for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December | |||
2017, <https://www.rfc-editor.org/info/rfc8298>. | 2017, <https://www.rfc-editor.org/info/rfc8298>. | |||
[RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, | [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, | |||
"Shared Bottleneck Detection for Coupled Congestion | "Shared Bottleneck Detection for Coupled Congestion | |||
Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, | Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, | |||
June 2018, <https://www.rfc-editor.org/info/rfc8382>. | June 2018, <https://www.rfc-editor.org/info/rfc8382>. | |||
[RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- | ||||
Assisted Dynamic Adaptation (NADA): A Unified Congestion | ||||
Control Scheme for Real-Time Media", RFC 8698, | ||||
DOI 10.17487/RFC8698, February 2020, | ||||
<https://www.rfc-editor.org/info/rfc8698>. | ||||
Authors' Addresses | Authors' Addresses | |||
Zaheduzzaman Sarker | Zaheduzzaman Sarker | |||
Ericsson AB | Ericsson AB | |||
Torshamnsgatan 21 | Torshamnsgatan 21 | |||
Stockholm 164 40 | Stockholm 164 40 | |||
Sweden | Sweden | |||
Phone: +46107173743 | Phone: +46107173743 | |||
Email: zaheduzzaman.sarker@ericsson.com | Email: zaheduzzaman.sarker@ericsson.com | |||
End of changes. 14 change blocks. | ||||
37 lines changed or deleted | 37 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/ |