WG Action: Formed Congestion Control Working Group (ccwg)
A new IETF WG has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Congestion Control Working Group (ccwg) --- Current status: Proposed WG Chairs: Eric Kinnear Reese Enghardt Assigned Area Director: Zaheduzzaman Sarker Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: c...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ccwg Archive: https://mailarchive.ietf.org/arch/browse/ccwg/ Group page: https://datatracker.ietf.org/group/ccwg/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ccwg/ RFC 5033 describes a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed. Congestion control algorithm proponents now often have the opportunity to test and deploy at scale without IETF review. The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond. There is more interest in specialized use cases such as data centers and real-time protocols. Finally, the community has gained much more experience with indications of congestion beyond packet loss. The Congestion Control Working Group will analyze some of the impediments to congestion control work occurring in the IETF and can generalize transports from TCP to all of the relevant transport protocols. This will inform a revision of RFC 5033 (5033bis) that encourages IETF review of congestion control proposals and standardization of mature congestion control algorithms. The congestion control expertise in the working group also makes it a natural venue to take on other work related to indications of congestion such as delay, queuing algorithms, rate pacing, multipath, interaction with other layers, among others. In particular, it can address congestion control algorithms with empirical evidence of safety (for example - avoiding congestion collapse) and stated intent to deploy by major implementations. The working group is intended to be a home for such work, and it is chartered to adopt proposals in this space if such congestion control algorithms are presented before or after the completion of the primary deliverable i.e. 5033bis. The group will coordinate closely with other relevant working and research groups, including ICCRG, TCPM, QUIC, and TSVWG. Documents in CCWG will remain as transport protocol agnostic as possible, but they may have short specific instructions, such as header options or parameter formats, for one or more protocols. Documents that are wholly specific to mechanisms in a single protocol will remain in the maintenance working group for that protocol. Algorithms proposed for Experimental status, in consultation with ICCRG, based on an assessment of their maturity and likelihood of near-term wide-scale deployment, are in scope. Publication of Informational RFCs analyzing the published standard congestion control algorithms is within CCWG scope. However, it is not chartered to document the state of congestion control in the Internet, including assessments of whether any particular implementation complies with existing standards. Other venues, such as the IRTF, may be more appropriate for publishing such documents. Milestones: Jun 2024 - Submit 5033bis to IESG for publication. Dec 2024 - Submit an Informational RFC analyzing the published standard congestion controllers ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Congestion Control Working Group (ccwg)
A new IETF WG has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-06-11. Congestion Control Working Group (ccwg) --- Current status: Proposed WG Chairs: Eric Kinnear Reese Enghardt Assigned Area Director: Zaheduzzaman Sarker Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: c...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ccwg Archive: https://mailarchive.ietf.org/arch/browse/ccwg/ Group page: https://datatracker.ietf.org/group/ccwg/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ccwg/ RFC 5033 describes a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed. Congestion control algorithm proponents now often have the opportunity to test and deploy at scale without IETF review. The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond. There is more interest in specialized use cases such as data centers and real-time protocols. Finally, the community has gained much more experience with indications of congestion beyond packet loss. The Congestion Control Working Group will analyze some of the impediments to congestion control work occurring in the IETF and can generalize transports from TCP to all of the relevant transport protocols. This will inform a revision of RFC 5033 (5033bis) that encourages IETF review of congestion control proposals and standardization of mature congestion control algorithms. The congestion control expertise in the working group also makes it a natural venue to take on other work related to indications of congestion such as delay, queuing algorithms, rate pacing, multipath, interaction with other layers, among others. In particular, it can address congestion control algorithms with empirical evidence of safety (for example - avoiding congestion collapse) and stated intent to deploy by major implementations. The working group is intended to be a home for such work, and it is chartered to adopt proposals in this space if such congestion control algorithms are presented before or after the completion of the primary deliverable i.e. 5033bis. The group will coordinate closely with other relevant working and research groups, including ICCRG, TCPM, QUIC, and TSVWG. Documents in CCWG will remain as transport protocol agnostic as possible, but they may have short specific instructions, such as header options or parameter formats, for one or more protocols. Documents that are wholly specific to mechanisms in a single protocol will remain in the maintenance working group for that protocol. Algorithms proposed for Experimental status, in consultation with ICCRG, based on an assessment of their maturity and likelihood of near-term wide-scale deployment, are in scope. Publication of Informational RFCs analyzing the published standard congestion control algorithms is within CCWG scope. However, it is not chartered to document the state of congestion control in the Internet, including assessments of whether any particular implementation complies with existing standards. Other venues, such as the IRTF, may be more appropriate for publishing such documents. Milestones: - Submit 5033bis to IESG for publication. - Submit an Informational RFC analyzing the published standard congestion controllers Milestones: ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9392 on Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences
A new Request for Comments is now available in online RFC libraries. RFC 9392 Title: Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences Author: C. Perkins Status: Informational Stream: IETF Date: April 2023 Mailbox:c...@csperkins.org Pages: 17 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-rtp-cc-feedback-12.txt URL:https://www.rfc-editor.org/info/rfc9392 DOI:10.17487/RFC9392 This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for implementing congestion control for unicast multimedia applications. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences' to Informational RFC (draft-ietf-rmcat-rtp-cc-feedback-12.txt)
The IESG has approved the following document: - 'Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences' (draft-ietf-rmcat-rtp-cc-feedback-12.txt) as Informational RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/ Technical Summary This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and its suitability for implementing congestion control for unicast multimedia applications. Working Group Summary There seems general, but not overwhelming, consensus from the working group that an informational document describing the ways the congestion control feedback can be sent can provide useful guidance for developers. There has been no controversy or disagreement around the document. Document Quality During its development, the document was presented to and reviewed by members of the avtcore wg, in addition to the members of the rmcat wg. No need for additional review from other IETF working groups or external organizations has been identified. Personnel Document shepherd : Anna Brunström Area Director : Zaheduzzaman Sarker ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences) to Informational RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-08-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo discusses the types of congestion control feedback that it is possible to send using the RTP Control Protocol (RTCP), and their suitability of use in implementing congestion control for unicast multimedia applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-rtp-cc-feedback/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9265 on Forward Erasure Correction (FEC) Coding and Congestion Control in Transport
A new Request for Comments is now available in online RFC libraries. RFC 9265 Title: Forward Erasure Correction (FEC) Coding and Congestion Control in Transport Author: N. Kuhn, E. Lochin, F. Michel, M. Welzl Status: Informational Stream: IRTF Date: July 2022 Mailbox:nicolas.kuhn.i...@gmail.com, emmanuel.loc...@enac.fr, francois.mic...@uclouvain.be, mich...@ifi.uio.no Pages: 21 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-nwcrg-coding-and-congestion-12.txt URL:https://www.rfc-editor.org/info/rfc9265 DOI:10.17487/RFC9265 Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document. This document is a product of the Coding for Efficient Network Communications Research Group of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist https://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9002 on QUIC Loss Detection and Congestion Control
A new Request for Comments is now available in online RFC libraries. RFC 9002 Title: QUIC Loss Detection and Congestion Control Author: J. Iyengar, Ed., I. Swett, Ed. Status: Standards Track Stream: IETF Date: May 2021 Mailbox:jri.i...@gmail.com, iansw...@google.com Pages: 42 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-quic-recovery-34.txt URL:https://www.rfc-editor.org/info/rfc9002 DOI:10.17487/RFC9002 This document describes loss detection and congestion control mechanisms for QUIC. This document is a product of the QUIC Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'QUIC Loss Detection and Congestion Control' to Proposed Standard (draft-ietf-quic-recovery-34.txt)
The IESG has approved the following document: - 'QUIC Loss Detection and Congestion Control' (draft-ietf-quic-recovery-34.txt) as Proposed Standard This document is the product of the QUIC Working Group. The IESG contact persons are Martin Duke and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ Technical Summary: QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted transport protocol. Its main features are minimizing connection establishment and overall transport latency for applications such as HTTP/3, providing multiplexing without head-of-line blocking, requiring only changes to path endpoints to enable deployment, providing always-secure transport using TLS 1.3. This document set specifies the QUIC transport protocol and it version-independent invariants, its loss detection and recovery approach, its use of TLS1.3 for providing security, and a new version of HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in that protocol. Working Group Summary: As can be expected, discussion on many aspects of QUIC was quite intense. The resulting consensus, however, was judged by the chairs to be both strong and broad. Document Quality: There are over twenty implementations of QUIC that are participating in interop testing, including all major web browsers and many server, CDN and standalone library implementations. The acknowledgements sections of the I-Ds highlight the individuals that made major contributions to a given document. Personnel: The document shepherds for the individual I-Ds are: - Lucas Pardue: - draft-ietf-quic-http - draft-ietf-quic-qpack - Lars Eggert: - draft-ietf-quic-transport - draft-ietf-quic-recovery - Mark Nottingham: - draft-ietf-quic-tls - draft-ietf-quic-invariants The responsible AD for the document set is Magnus Westerlund. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8888 on RTP Control Protocol (RTCP) Feedback for Congestion Control
A new Request for Comments is now available in online RFC libraries. RFC Title: RTP Control Protocol (RTCP) Feedback for Congestion Control Author: Z. Sarker, C. Perkins, V. Singh, M. Ramalho Status: Standards Track Stream: IETF Date: January 2021 Mailbox:zaheduzzaman.sar...@ericsson.com, c...@csperkins.org, varun.si...@iki.fi, ma...@cornell.edu Pages: 13 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avtcore-cc-feedback-message-09.txt URL:https://www.rfc-editor.org/info/rfc DOI:10.17487/RFC An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8868 on Evaluating Congestion Control for Interactive Real-Time Media
A new Request for Comments is now available in online RFC libraries. RFC 8868 Title: Evaluating Congestion Control for Interactive Real-Time Media Author: V. Singh, J. Ott, S. Holmer Status: Informational Stream: IETF Date: January 2021 Mailbox:varun.si...@iki.fi, o...@in.tum.de, hol...@google.com Pages: 13 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-eval-criteria-14.txt URL:https://www.rfc-editor.org/info/rfc8868 DOI:10.17487/RFC8868 The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8867 on Test Cases for Evaluating Congestion Control for Interactive Real-Time Media
A new Request for Comments is now available in online RFC libraries. RFC 8867 Title: Test Cases for Evaluating Congestion Control for Interactive Real-Time Media Author: Z. Sarker, V. Singh, X. Zhu, M. Ramalho Status: Informational Stream: IETF Date: January 2021 Mailbox:zaheduzzaman.sar...@ericsson.com, varun.si...@iki.fi, xiaoq...@cisco.com, ma...@cornell.edu Pages: 28 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-eval-test-10.txt URL:https://www.rfc-editor.org/info/rfc8867 DOI:10.17487/RFC8867 The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8836 on Congestion Control Requirements for Interactive Real-Time Media
A new Request for Comments is now available in online RFC libraries. RFC 8836 Title: Congestion Control Requirements for Interactive Real-Time Media Author: R. Jesup, Z. Sarker, Ed. Status: Informational Stream: IETF Date: January 2021 Mailbox:randell-i...@jesup.org, zaheduzzaman.sar...@ericsson.com Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-cc-requirements-09.txt URL:https://www.rfc-editor.org/info/rfc8836 DOI:10.17487/RFC8836 Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RTP Control Protocol (RTCP) Feedback for Congestion Control' to Proposed Standard (draft-ietf-avtcore-cc-feedback-message-09.txt)
The IESG has approved the following document: - 'RTP Control Protocol (RTCP) Feedback for Congestion Control' (draft-ietf-avtcore-cc-feedback-message-09.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-cc-feedback-message/ Technical Summary: This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control. Working Group Summary: The document was reviewed by the WG and went through WG last call and had the WG consensus Document Quality: The feedback message was tested in a recent Hackathon and is used for the RMCAT WG work. Sergio Mena, Nils Olhmeier and Jonathan Lennox had interop implementations at the Hackathon. Ingemar Johansson also provided good feedback. Personnel: Bernard Aboba is the document shepherd. Barry Leiba is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (QUIC Loss Detection and Congestion Control) to Proposed Standard
The IESG has received a request from the QUIC WG (quic) to consider the following document: - 'QUIC Loss Detection and Congestion Control' as Proposed Standard This document is part of a combined 26-day last call for multiple related documents that defines the QUIC protocol and the HTTP mapping onto QUIC. The documents are: - draft-ietf-quic-transport - draft-ietf-quic-recovery - draft-ietf-quic-tls - draft-ietf-quic-invariants - draft-ietf-quic-http - draft-ietf-quic-qpack Due to its GitHub-centric work style, the QUIC WG requests that LC review comments are individually filed as issues in the WG repository at https://github.com/quicwg/base-drafts if at all possible. A summary email with URLs to the individual issue should then also be sent to the relevant mailing list (primarily last-c...@ietf.org and q...@ietf.org). The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-11-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (q...@ietf.org (mailto:q...@ietf.org)), which is archived at https://mailarchive.ietf.org/arch/ search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2910/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (RTP Control Protocol (RTCP) Feedback for Congestion Control) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'RTP Control Protocol (RTCP) Feedback for Congestion Control' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-09-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-cc-feedback-message/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Evaluating Congestion Control for Interactive Real-time Media' to Informational RFC (draft-ietf-rmcat-eval-criteria-14.txt)
The IESG has approved the following document: - 'Evaluating Congestion Control for Interactive Real-time Media' (draft-ietf-rmcat-eval-criteria-14.txt) as Informational RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Mirja Kühlewind and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ Technical Summary The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This draft describes guidelines for how to evaluate new congestion control algorithms for interactive point-to-point real-time media. Working Group Summary This draft started early in the lifetime of the working group. There was some extensive discussion leading up to its adoption as a working group draft at IETF 89. Since then, the scope has gradually narrowed and some work has been split out into draft-ietf-rmcat-eval-test, but there has been little controversy - slow progress has been rather a sign that the group has focussed on congestion control algorithm design, rather than on revising the evaluation criteria. Document Quality No media type, MIB doctor, or similar expert review needed. The working draft has seen several evaluations of congestion control algorithms such as NADA and SCReAM, and these have been based on the evaluation criteria described in this draft, and in the other evaluation drafts. The criteria seem mature and have been implemented. Personnel The shepherd is Colin Perkins. The responsible area directory is Mirja Kühlewind. RFC Editor Note Nit: In section 2 last word should be "applies" instead of "apply" as Barry kindly pointed out. Editors forgot to fix that nit in the last revision. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Evaluating Congestion Control for Interactive Real-time Media) to Informational RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Evaluating Congestion Control for Interactive Real-time Media' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-02-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rmcat-eval-criteria/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8698 on Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media
A new Request for Comments is now available in online RFC libraries. RFC 8698 Title: Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media Author: X. Zhu, R. Pan, M. Ramalho, S. Mena Status: Experimental Stream: IETF Date: February 2020 Mailbox:xiaoq...@cisco.com, rong@intel.com, ma...@cornell.edu, sem...@cisco.com Pages: 26 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-nada-13.txt URL:https://www.rfc-editor.org/info/rfc8698 DOI:10.17487/RFC8698 This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8699 on Coupled Congestion Control for RTP Media
A new Request for Comments is now available in online RFC libraries. RFC 8699 Title: Coupled Congestion Control for RTP Media Author: S. Islam, M. Welzl, S. Gjessing Status: Experimental Stream: IETF Date: UNKNOWN Mailbox:safiq...@ifi.uio.no, mich...@ifi.uio.no, ste...@ifi.uio.no Pages: 20 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-coupled-cc-09.txt URL:https://www.rfc-editor.org/info/rfc8699 DOI:10.17487/RFC8699 When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'NADA: A Unified Congestion Control Scheme for Real-Time Media' to Experimental RFC (draft-ietf-rmcat-nada-13.txt)
The IESG has approved the following document: - 'NADA: A Unified Congestion Control Scheme for Real-Time Media' (draft-ietf-rmcat-nada-13.txt) as Experimental RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Mirja Kühlewind and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ Technical Summary This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. Working Group Summary The document has been reviewed of the RMCAT WG and there have been no controversial points. Document Quality The presented approach was evaluated based on the evaluation criteria and test cases developed in the RMCAT WG. Results and updates have been presented at various IETF meetings. The draft was cross-reviewed by the authors of competing schemes in the working group. Personnel The document shepherd is Martin Stiemerling (mls.i...@gmail.com). The responsible AD is Mirja Kuehlewind (i...@kuehlewind.net). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (NADA: A Unified Congestion Control Scheme for Real-Time Media) to Experimental RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'NADA: A Unified Congestion Control Scheme for Real-Time Media' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-08-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2890/ https://datatracker.ietf.org/ipr/2671/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8593 on Video Traffic Models for RTP Congestion Control Evaluations
A new Request for Comments is now available in online RFC libraries. RFC 8593 Title: Video Traffic Models for RTP Congestion Control Evaluations Author: X. Zhu, S. Mena, Z. Sarker Status: Informational Stream: IETF Date: May 2019 Mailbox:xiaoq...@cisco.com, sem...@cisco.com, zaheduzzaman.sar...@ericsson.com Pages: 19 Characters: 44193 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-video-traffic-model-07.txt URL:https://www.rfc-editor.org/info/rfc8593 DOI:10.17487/RFC8593 This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'Video Traffic Models for RTP Congestion Control Evaluations' to Informational RFC (draft-ietf-rmcat-video-traffic-model-07.txt)
The IESG has approved the following document: - 'Video Traffic Models for RTP Congestion Control Evaluations' (draft-ietf-rmcat-video-traffic-model-07.txt) as Informational RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/ Technical Summary This document describes two reference video traffic models for evaluating RTP congestion control algorithms. One is based on a statistical model of a live video encoder, the other is trace-driven and models the output of a real video encoder. These are intended to supply input data to be used during evaluation of congestion control algorithms for interactive RTP media flows under development in the RMCAT working group. Working Group Summary The initial individual draft was submitted for IETF 91, and was adopted as a working group draft for IETF 95. Development has not moved quickly, but there was little controversy. Rather, the relatively slow pace of development reflects a desire to ensure the model is realistic and is implementable. Document Quality The authors have made available an open source implementation of the model described in the draft. The draft has been widely reviewed by the working group over a number of years. There is no need for MIB doctor, media type, or other expert review, Personnel The document shepherd is Colin Perkins. The responsible AD is Mirja Kuehlewind.
Last Call: (Video Traffic Models for RTP Congestion Control Evaluations) to Informational RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Video Traffic Models for RTP Congestion Control Evaluations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-01-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on target video rate. The second model is trace-driven, and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8382 on Shared Bottleneck Detection for Coupled Congestion Control for RTP Media
A new Request for Comments is now available in online RFC libraries. RFC 8382 Title: Shared Bottleneck Detection for Coupled Congestion Control for RTP Media Author: D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth Status: Experimental Stream: IETF Date: June 2018 Mailbox:dav...@simula.no, sim...@ferlin.io, mich...@ifi.uio.no, krist...@ifi.uio.no Pages: 25 Characters: 49095 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rmcat-sbd-11.txt URL:https://www.rfc-editor.org/info/rfc8382 DOI:10.17487/RFC8382 This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. This document is a product of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
EXTENDED Last Call: (Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.) to Experimental RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.) to Experimental RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-03-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rmcat-sbd/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8257 on Data Center TCP (DCTCP): TCP Congestion Control for Data Centers
A new Request for Comments is now available in online RFC libraries. RFC 8257 Title: Data Center TCP (DCTCP): TCP Congestion Control for Data Centers Author: S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd Status: Informational Stream: IETF Date: October 2017 Mailbox:sb...@microsoft.com, dtha...@microsoft.com, pr...@microsoft.com, l...@netapp.com, glenn.j...@morganstanley.com Pages: 17 Characters: 37357 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-dctcp-10.txt URL:https://www.rfc-editor.org/info/rfc8257 DOI:10.17487/RFC8257 This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'Coupled congestion control for RTP media' to Experimental RFC (draft-ietf-rmcat-coupled-cc-07.txt)
The IESG has approved the following document: - 'Coupled congestion control for RTP media' (draft-ietf-rmcat-coupled-cc-07.txt) as Experimental RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ Technical Summary The RMCAT working group is developing congestion control schemes for use with RTP. When multiple such congestion controlled RTP flows traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the NADA congestion control algorithm, and provides suggestions on how to apply it to other congestion control algorithms. Working Group Summary The draft has been under development in the working group for some years. Much of the time was taken waiting for the candidate congestion control algorithms to stabilise, mapping the algorithms to the mechanisms given in this draft, and deciding which congestion control algorithms should be supported. The coupled congestion control algorithm itself has proved reasonably stable. The draft discusses how to apply coupled congestion control to NADA and Google Congestion Control. The mapping to NADA is in the main body of the draft, since NADA is nearing working group last call and believed stable. The mapping for Google Congestion Control is in an appendix, since Google Congestion Control is not yet finalised. There is no mapping for SCReAM at this time, but one could be added later if there was interest in doing so (nothing in SCReAM should prevent this). Overall, the working group process has been relatively smooth, although not rapid. The main issue of contention was the choice of congestion control algorithm to which the mechanism should be applied - based on the maturity of the candidate congestion control algorithms, and the relative importance the authors of the candidates placed on coupled congestion control. Document Quality The algorithm has been implemented in simulations and emulated testbeds. This is appropriate for an experimental protocol of this type, and meets the usual community evaluation standards for transport protocol research. The draft has been reviewed by some authors of each candidate congestion control algorithm, with Xiaoqing Zhu and Stefan Holmer providing detailed reviews and advice on integration with the congestion control proposals. The draft is well written, and the mechanism is clearly specified. There is no need for MIB Doctor, Media Type, or other expert review, since the proposed mechanism relies only on common RTP features and parameters that can be directly measured by the end-point using the mechanism. Personnel The document shepherd is Colin Perkins. The responsible AS is Mirja Kühlewind.
Document Action: 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' to Informational RFC (draft-ietf-tcpm-dctcp-10.txt)
The IESG has approved the following document: - 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' (draft-ietf-tcpm-dctcp-10.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ Technical Summary This informational memo describes Datacenter TCP (DCTCP). DCTCP is an improvement to TCP congestion control for datacenter traffic that uses Explicit Congestion Notification (ECN). DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters, but it must not be deployed over the public Internet without additional measures. The document is published to document an implementation in the Microsoft Windows Server 2012 operating system. The Linux and FreeBSD operating systems have also implemented support for DCTCP. Working Group Summary The TCPM working group has reviewed the document regarding clarity and comprehensiveness of the protocol specification, e.g. in corner cases. The document has been discussed multiple times in the working group without any major controversy. During the working group last call there have been several detailed reviews, and those comments have been addressed in the most recent version. All in all, there is very strong consensus in the TCPM working group that this document should be published. Document Quality The document describes DCTCP as implemented in Microsoft Windows Server 2012. Since the publication of the first versions of the document, the Linux and FreeBSD operating systems have also implemented support for DCTCP. The specification should also enable implementation in other TCP stacks. The objective of this informational memo is to document an alternative TCP congestion control algorithm that is known to be widely deployed. It is consensus in the TCPM working group that a DCTCP standard would require further work. A precise documentation of running code enables follow-up experimental or standards track RFCs. Personnel The document shepherd is Michael Scharf <michael.sch...@nokia.com>. The responsible Area Director is Mirja Kuehlewind <i...@kuehlewind.net>.
Last Call: (Coupled congestion control for RTP media) to Experimental RFC
The IESG has received a request from the RTP Media Congestion Avoidance Techniques WG (rmcat) to consider the following document: - 'Coupled congestion control for RTP media' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-08-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract When multiple congestion controlled RTP sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the NADA congestion control algorithm, and provides suggestions on how to apply it to other congestion control algorithms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8095 on Services Provided by IETF Transport Protocols and Congestion Control Mechanisms
A new Request for Comments is now available in online RFC libraries. RFC 8095 Title: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms Author: G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed. Status: Informational Stream: IETF Date: March 2017 Mailbox:go...@erg.abdn.ac.uk, i...@trammell.ch, mirja.kuehlew...@tik.ee.ethz.ch Pages: 54 Characters: 126843 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-taps-transports-14.txt URL:https://www.rfc-editor.org/info/rfc8095 DOI:10.17487/RFC8095 This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. This document is a product of the Transport Services Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 8083 on Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
A new Request for Comments is now available in online RFC libraries. RFC 8083 Title: Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions Author: C. Perkins, V. Singh Status: Standards Track Stream: IETF Date: March 2017 Mailbox:c...@csperkins.org, va...@callstats.io Pages: 25 Characters: 67197 Updates:RFC 3550 I-D Tag:draft-ietf-avtcore-rtp-circuit-breakers-18.txt URL:https://www.rfc-editor.org/info/rfc8083 DOI:10.17487/RFC8083 The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: (Services provided by IETF transport protocols and congestion control mechanisms) to Informational RFC
The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'Services provided by IETF transport protocols and congestion control mechanisms' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-09-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes, surveys, classifies and compares the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ballot/ No IPR declarations have been submitted directly on this I-D. Please note that this Last Call period has been extended to accommodate the end of August vacation season.
Protocol Action: 'Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions' to Proposed Standard (draft-ietf-avtcore-rtp-circuit-breakers-18.txt)
The IESG has approved the following document: - 'Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions' (draft-ietf-avtcore-rtp-circuit-breakers-18.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ Technical Summary The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This acts as a safety measure to prevent starvation of network resources denying other flows from access to the Internet, such measures are essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP circuit- breakers. Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. Working Group Summary The WG has been quite diligent in working on this. There has been discussion if the specification addresses the right issue, and if the perimeter behavior it establish is the appropriate one. That consensus is definitely a rough consensus. A very good number of people have commented on the specification. Document Quality There has been significant input, including simulations both for wired and wireless networks, the result of these simulations are referenced by the specification. Simon Perreault at JIVE did a trial deployment in their service. All of this has helped improving the solution and its definition significantly and helped verifying the behavior of the circuit breakers. Personnel Magnus Westerlund is the document shepherd. Responsible AD is Ben Campbell
Last Call: (Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions) to Proposed Standard
The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This acts as a safety measure to prevent starvation of network resources denying other flows from access to the Internet, such measures are essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP circuit- breakers. Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'Congestion Control Requirements for Interactive Real-Time Media' to Informational RFC (draft-ietf-rmcat-cc-requirements-09.txt)
The IESG has approved the following document: - 'Congestion Control Requirements for Interactive Real-Time Media' (draft-ietf-rmcat-cc-requirements-09.txt) as Informational RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ Technical Summary The document describes requirements for real-time media congestion control. With the standardization of RTCWeb, an increasing amount of real-time media is expected in the Internet and this traffic needs to be appropriately congestion- controlled. Real-time media traffic has quite different requirements for congestion control as compared to most Internet traffic. The requirements are listed in this document to develop and later evaluate a congestion control scheme that is more suitable for real-time media traffic than today's existing schemes. Working Group Summary There was quite a lot discussion in the working group on how to define fairness (mainly in respect to evaluation criteria document). For this document the working group decided to leave the definition of fairness open (to be addressed in the evaluation criteria document). Only self-fairness was defined (as roughly equal bandwidth). There was a discussion on RTT-fairness. This was added as an optional requirement (if possible). Additionally this document addresses requirements to handle different RTP streams multiplexed into one connection (5-tuple) or different DSCP markings within one connection. Those points were discussed on the RTCWeb and RMCAT mailing lists. Document Quality This document is an informational requirements document, thus there are no implementations... The document received several rounds of reviews in total of 10 different persons (including 4 in WGLC and 2 from people mainly working in RTCweb) leading to discussions with even more people involved. These discussions led to several additions and small modifications to the requirements. The document contains two references to other w-g documents of RTCWeb and RMCAT. Personnel Mirja Kühlewind (mirja.kuehlew...@ikr.uni-stuttgart.de) is Docoment Shepherd and one of the RMCAT working group chairs. Spencer Dawkins spencerdawkins.i...@gmail.com is the responsible Area Director.
RFC 7295 on Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
A new Request for Comments is now available in online RFC libraries. RFC 7295 Title: Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication Author: H. Tschofenig, L. Eggert, Z. Sarker Status: Informational Stream: IAB Date: July 2014 Mailbox:hannes.tschofe...@gmx.net, l...@netapp.com, zaheduzzaman.sar...@ericsson.com Pages: 26 Characters: 59655 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iab-cc-workshop-report-02.txt URL:http://www.rfc-editor.org/rfc/rfc7295.txt This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community. The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF). This document is a product of the Internet Architecture Board. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Call for Review of draft-iab-cc-workshop-report-01, Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
This is a call for review of Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-cc-workshop-report/ The Call for Review will last until 14 May 2014. Please send comments to i...@iab.org. On behalf of the IAB, Russ Housley IAB Chair
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
- Original Message - From: Cameron Byrne cb.li...@gmail.com To: Brian E Carpenter brian.e.carpen...@gmail.com Cc: bra...@isi.edu; IETF-Discussion ietf@ietf.org; Dearlove, Christopher (UK) chris.dearl...@baesystems.com; t.p. daedu...@btconnect.com Sent: Wednesday, March 06, 2013 4:12 PM On Mar 6, 2013 1:03 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 06/03/2013 08:36, t.p. wrote: ... Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Reading this reminds me that my first experience with TCP was over a high latency high jitter network with 0% error and 0% loss (to my ability to measure it) with retransmission rates of 50%, because the TCP algorithms were totally unsuited to such a network. It was, of course, X.25. Did anyone find a solution back then, or did we just wait for X.25 to be superseded? (I am back on my thesis that there is nothing new in Congestion Control, that the principles and practices that we need have been around for many years and that we just need to find them). Tom Petch Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the -middle-attacks-103799 Hold on to your hats. CB
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
- Original Message - From: Cameron Byrne cb.li...@gmail.com To: Dearlove, Christopher (UK) chris.dearl...@baesystems.com Cc: bra...@isi.edu; ietf@ietf.org Sent: Tuesday, March 05, 2013 8:01 PM On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: I've no idea about the example quoted, but I can see some of their motivation. snip In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as tcp optmization or WAN acceleration, both murky terms. tp Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? (It is true that the IETF did TCP without any skin in X.25, 802.3 and so on but this sounds different). Alternatively, when the ICCRG was looking for things to do, I did raise the question of how true it was that (presumed) packet loss was due to congestion (a fundamental assumption of the IETF) and got the impression that that was regarded as an answered question and not a topic for research. From what you say, it sounds more as if the ICCRG should have been looking at it. Tom Petch The issues in CC result is the re-invention of congestion control at higher layers like http://en.wikipedia.org/wiki/QUIC And, fun things like draft-ietf-rtcweb-data-channel CB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.ht ml That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
On 06/03/2013 08:36, t.p. wrote: ... Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Cameron Byrne wrote: In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. According to the end to end argument, that's simply impossible, because intermediate equipments holding packets not confirmed by the next hop may corrupt the packets or suddenly goes down. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, Even with moderate packet drop probability, it means *A LOT OF* delay or connection oriented communication, either of which makes 3GPP mostly unusable. Masataka Ohta
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
3GPP has to never drop a packet because it's doing zero-header compression. Lose a bit, lose everything. And ROHC is an IETF product. I'm pretty sure the saving on headers is more than made up for in FEC, delay, etc. Not the engineering tradeoff one might want. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Masataka Ohta [mo...@necom830.hpcl.titech.ac.jp] Sent: 06 March 2013 11:37 To: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Cameron Byrne wrote: In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. According to the end to end argument, that's simply impossible, because intermediate equipments holding packets not confirmed by the next hop may corrupt the packets or suddenly goes down. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, Even with moderate packet drop probability, it means *A LOT OF* delay or connection oriented communication, either of which makes 3GPP mostly unusable. Masataka Ohta
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
l.w...@surrey.ac.uk wrote: 3GPP has to never drop a packet because it's doing zero-header compression. has to never? Even though it must, when it goes down. Lose a bit, lose everything. You totally deny FEC. Wow!!! And ROHC is an IETF product. I'm pretty sure the saving on headers is more than made up for in FEC, delay, etc. Not the engineering tradeoff one might want. It has nothing to do with congestion, not at all. Masataka Ohta
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
On Mar 6, 2013 1:03 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 06/03/2013 08:36, t.p. wrote: ... Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799 Hold on to your hats. CB
RE: congestion control? - (was Re: Appointment of a Transport AreaDirector)
See also: http://www.akamai.com/html/about/press/releases/2012/press_091312.html Irrespectively Yours, John From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, March 06, 2013 8:12 AM To: Brian E Carpenter Cc: bra...@isi.edu; IETF-Discussion Subject: Re: congestion control? - (was Re: Appointment of a Transport AreaDirector) On Mar 6, 2013 1:03 AM, Brian E Carpenter brian.e.carpen...@gmail.commailto:brian.e.carpen...@gmail.com wrote: On 06/03/2013 08:36, t.p. wrote: ... Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799 Hold on to your hats. CB
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
From: t.p. daedu...@btconnect.com is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? I would _like_ to think it's better done by the IETF, since congestion control/response more or less has to be done on an end-end basis, so trying to do it in any particular link technology is not necessarily useful (unless the entire connection path is across that technology). But... From: Cameron Byrne cb.li...@gmail.com There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. Well, I sort of see the analogy with NAT. But rather than rathole on a non-productive discussion of similarities and causes, I think it's more useful/fruitful to examine your point that people are doing all sorts of localized hacks in an attempt to gain competitive advantage. Sometimes this is not a problem, and they are (rightly) responding to places where the IETF isn't meeting needs (one good example is traffic directors in front of large multi-machine web servers). But how much good going it alone will do in this particular case (since congestion control is necessarily end-end) is unclear, although I guess the 'terminate (effectively) the end-end connection near the border of the provider's system, and do a new one to the terminal at the user's device' model works. But there definitely is a risk of layers clashing, both trying to do one thing... Noel
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
John E Drake wrote: See also: http://www.akamai.com/html/about/press/releases/2012/press_091312.html It seems to me that Akamai is doing things which must be banned by IETF. Akamai IP Application Accelerator http://www.atoll.gr/media/brosures/FS_IPA.pdf Packet Loss Reduction Application performance is also affected by packet loss, which may be particularly troublesome when traffic traverses international network paths. IP Application ^^ Accelerator uses a variety of advanced ^^ packet loss reduction techniques, including ^^^ forward error correction and optional packet replication to eliminate packet loss. Masataka Ohta
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Martin, An article like this is the best reason why we should never finally resolve the buffer bloat issue: Doing that would take away the opportunity for generations of researcher to over and over regurgitate the same proposed improvements and gain PhDs in the process. I mean the Internet wold be like math without fermats last theorem. Have you seen how disenfranchised mathematicians are now ? Its worse than the mood at Kennedy Space center without a shuttle program (to bring the discussion back to relevant aspects of IETF Orlando). Sorry. could'nt resist. I was actually happy about using some of those UDP based flow control reliable transports in past years when i couldn't figure out how to fix the TCP stack of my OSs. Alas, the beginning of the end of TCP is near now anyhow with RTCweb deciding to use browser/user-level based SCTP over UDP stacks instead of OS-level TCP. On Tue, Mar 05, 2013 at 01:41:35AM +0100, Martin Rex wrote: Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin -- --- Toerless Eckert, eck...@cisco.com Cisco NSSTG Systems Technology Architecture SDN: Let me play with the network, mommy!
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 05, 2013 at 07:52:56AM +, Eggert, Lars wrote: On Mar 4, 2013, at 19:44, Michael Richardson mcr+i...@sandelman.ca wrote: The Transport Area has all of the groups that deal with transport protocols that need to do congestion control. Further, the (current) split of work means that all of the groups that need congestion oversight would be cared for by the position that is currently becoming empty as Wes leaves. Also, other areas frequently build protocols that need review from a congestion control perspective (do they back of under loss, can they even detect loss, etc.) Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot. Lars Sure, but that could equally well be seen as a problem of the way how the IESG chooses to perform its business. There are enough experts that could consult whether its in role of directorates or else. They may just not want to take on an AD role. And there are a lot more TSV friction points with whats going on in the IETF than just CC.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Roger, On 3/4/13 7:20 PM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) That basic question is a very important one to ask from time to time. Others have already answered, and I will simply add one addition: the way one implements congestion control (or not) has impact not only on the party or parties with whom your computer is speaking, but on every communication that shares the links between your computer and those parties. So: get it wrong and you can hurt others. And it's easy to get wrong. Eliot
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
The problem with the congestion/interference and corruption problem is that error notification does not percolate up the stack. If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints, TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost... first hops benefit most. in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does. And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow. And to make the header checks pass with a chance of decoding the headers have to be coded better than the payloads - and this applies at each layer, recursively. um. But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums. And a paucity of available state to track and associate with flows. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dearlove, Christopher (UK) [chris.dearl...@baesystems.com] Sent: 05 March 2013 11:55 To: m...@sap.com; bra...@isi.edu Cc: ietf@ietf.org Subject: RE: congestion control? - (was Re: Appointment of a Transport Area Director) I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 8:15 AM, Brian E Carpenter wrote: On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian TRIGTRAN tried to nail this down in more detail after PILC concluded (I co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 minutes pretty much captured where that ended up: quote Spencer summarized a private conversation with Mark Allman as, Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad /quote If we had to have all the TCP responding-to-loss mechanisms in an implementation anyway, and we could tell a sender to slow down, but not to speed up, it wasn't clear that additional mechanisms would buy you much. References are at http://www.ietf.org/proceedings/55/239.htm and http://www.ietf.org/proceedings/56/251.htm The high order bit on this may have been that TRIGTRAN wasn't IETF-ready and should have gone off to visit IRTF-land, but in the early 2000s, I (at least) had no idea how to make that happen. Spencer I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions.
Fwd: [e2e] Why do we need congestion control?
Begin forwarded message: From: Srinivasan Keshav kes...@uwaterloo.ca Subject: [e2e] Why do we need congestion control? Date: March 5, 2013 15:04:48 GMT+01:00 To: end2end-inter...@postel.org end2end-inter...@postel.org To answer this question, I put together some slides for a presentation at the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always size a shared resource (such as a link or a router) smaller than the sum of peak demands. This can result in transient or persistent overloads, reducing user-perceived performance. Transient overloads are easily relieved by a buffer, but persistent overload requires reductions of source loads, which is the role of congestion control. Lacking congestion control, or worse, with an inappropriate response to a performance problem (such as by increasing the load), shared network resources are always overloaded leading to delays, losses, and eventually collapse, where every packet that is sent is a retransmission and no source makes progress. A more detailed description can also be found in chapter 1 of my PhD thesis [2]. Incidentally, the distributed optimization approach that Jon mentioned is described beautifully in [3]. hope this helps, keshav [1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, published as UC Berkeley TR-654, September 1991 http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf [3] Palomar, Daniel P., and Mung Chiang. A tutorial on decomposition methods for network utility maximization. Selected Areas in Communications, IEEE Journal on 24.8 (2006): 1439-1451. http://www.princeton.edu/~chiangm/decomptutorial.pdf
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 10:40 AM, Spencer Dawkins wrote: On 3/5/2013 8:15 AM, Brian E Carpenter wrote: On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian TRIGTRAN tried to nail this down in more detail after PILC concluded (I co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 minutes pretty much captured where that ended up: quote Spencer summarized a private conversation with Mark Allman as, Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad /quote If we had to have all the TCP responding-to-loss mechanisms in an implementation anyway, and we could tell a sender to slow down, but not to speed up, it wasn't clear that additional mechanisms would buy you much. References are at http://www.ietf.org/proceedings/55/239.htm and http://www.ietf.org/proceedings/56/251.htm The high order bit on this may have been that TRIGTRAN wasn't IETF-ready and should have gone off to visit IRTF-land, but in the early 2000s, I (at least) had no idea how to make that happen. Later on, there was also a proposed TERNLI BoF and mailing list, and bar BoF that resulted in: http://tools.ietf.org/id/draft-sarolahti-tsvwg-crosslayer-01.txt But didn't go any farther, that I'm aware of. Section 6 actually puts into context TRIGTRAN and other attempts to do something in this space. There's quite a bit of history just in the IETF. RFC 4907 (IAB's Architectural Implications of Link Indications) is also a good snapshot of the thinking at that time. -- Wes Eddy MTI Systems
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as tcp optmization or WAN acceleration, both murky terms. The issues in CC result is the re-invention of congestion control at higher layers like http://en.wikipedia.org/wiki/QUIC And, fun things like draft-ietf-rtcweb-data-channel CB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 3:01 PM, Cameron Byrne wrote: In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as tcp optmization or WAN acceleration, both murky terms. There may be some things the IETF can do to improve this. It's not clear yet, but some of the relevant vendors are participating in a non-WG mailing list, focused on one aspect of the situation (TCP option numbers), but recently more ambitious work was suggested: http://www.ietf.org/mail-archive/web/middisc/current/msg00121.html People who are interested in this, should *definitely* self-organize a bit and think about a BoF, in my opinion. -- Wes Eddy MTI Systems
congestion control? - (was Re: Appointment of a Transport Area Director)
changed the subject ... and added a cc to some that might not follow ietf@ On Sun, Mar 3, 2013 at 1:50 PM, Eggert, Lars l...@netapp.com wrote: On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com wrote: There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. Since I believe neither is the case, it sounds like the IESG requirements are too tight. I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control. The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment. I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
rgensen == rgensen Roger writes: rgensen I'll ask a rather basic question and hope someone will rgensen answer in an educational way - Why is congestion control so rgensen important? And where does it apply? ... :-) The Transport Area has all of the groups that deal with transport protocols that need to do congestion control. Further, the (current) split of work means that all of the groups that need congestion oversight would be cared for by the position that is currently becoming empty as Wes leaves. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgp_x2V_NHXrF.pgp Description: PGP signature
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It applies to everyone who sends packets into the Internet, potentially. OTOH, it is a collective phenomenon; as long as most Internet users are using TCP, it does not matter much what an individual non-TCP user does. TCP comes with the Gold Standard congestion control. Maybe the IETF could and should invite Van Jacobson to attend ab IETF meeting to reprise one of his talks from 20 years ago. Bob Braden
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Mar 4, 2013, at 19:44, Michael Richardson mcr+i...@sandelman.ca wrote: The Transport Area has all of the groups that deal with transport protocols that need to do congestion control. Further, the (current) split of work means that all of the groups that need congestion oversight would be cared for by the position that is currently becoming empty as Wes leaves. Also, other areas frequently build protocols that need review from a congestion control perspective (do they back of under loss, can they even detect loss, etc.) Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot. Lars
WG Action: Conclusion of Datagram Congestion Control Protocol (dccp)
The Datagram Congestion Control Protocol (dccp) working group in the Transport Area has concluded after having completed all of its chartered work. The IESG contact persons are Wesley Eddy and Martin Stiemerling. The DCCP mailing list (d...@ietf.org) will remain open in order to enable continued discussion among people that are implementing or using DCCP.
Protocol Action: 'Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)' to Proposed Standard (draft-ietf-dccp-udpencap-11.txt)
The IESG has approved the following document: - 'Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)' (draft-ietf-dccp-udpencap-11.txt) as Proposed Standard This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ Technical Summary The document specifies a mechanism to encapsulate DCCP packets in UDP datagrams, to support NAT traversal through devices that do not support DCCP natively. It also discusses various interactions related to encapsulation, such as those related to MTU discovery or ECN processing, and interactions with higher level protocols. Working Group Summary The DCCP working group has been generally supportive of the document. It went through three working group last calls; starting on August 2010, February 2011, and April 2012. All WGLCs have been forwarded also to TSVWG working group, and the second WGLC was announced in MMUSIC working group. During the first WGLC, various technical fixes were proposed. The second WGLC proposed integration with NAT traversal signaling solutions such as ICE. However, specifying this was considered to be a significant effort, and not within DCCP WG's expertise, so it was decided that these interactions will be specified in a separate document. The third WGLC on the current version of the document was concluded without comments. Given all these iterations and cross-WG review, the shepherd thinks the document has gone through a good review. Document Quality As indicated above, the document went through a cross-WG review with TSVWG and MMUSIC WGs. Some individual implementation prototypes of the earlier version of the specification have been made, but at the moment no implementation activities on this specification are known. Personnel Document Shepherd is Pasi Sarolahti pasi.sarola...@iki.fi Responsible Area Director is Wesley Eddy w...@mti-systems.com.
IAB/IRTF Congestion Control Workshop Papers Posted
The IAB and IRTF will be holding a workshop on Congestion Control for Interactive Real-Time Communications in Vancouver, CA on July 28, 2012. For more information, see: http://www.iab.org/cc-workshop/ The workshop papers are now posted and available for download here: http://www.iab.org/wp-content/IAB-uploads/2012/05/irtf_iab-ccirtcpapers.zip
Support for Remote Participation at the July 28 IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication
The Program Committee has received inquiries about remote participation at the IAB/IRTF Congestion Control Workshop to be held on July 28, 2012 in Vancouver, Canada. While participants are strongly encouraged to attend the meeting in person, arrangements for remote participation are planned (for those with accepted papers). Therefore if you were considering submitting a paper but could not make the workshop in person, we would encourage you to go ahead and submit; please indicate in your submission if you are only able to participate remotely. Call for Papers The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting. More information on the workshop is available at http://www.iab.org/cc-workshop/ This is an invitation-only workshop. Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. The focus should be on the problems and challenges that exist, rather than a detailed solution. If your expertise allows you to write about a range of topics, please pick the one topic you think would bring the most value to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Authors of accepted papers will be invited to the workshop. Accepted position papers will be published. Please use the following Website for submitting your papers: http://iab.org/ccirtc/paper?p=new Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Note: please contact us if you are interested in submitting a paper but have an issue with the submission deadline. IPR Policy Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop. Privacy Notice Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings). Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers. There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions. Meeting Venue The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html). Additional details about the meeting venue will be provided to authors of accepted papers. While participants are strongly encouraged to attend the meeting in person, arrangements for remote participation are planned (for those with accepted papers). Please indicate in your submission if you are only able to participate remotely. Sponsorship If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! Contact Information In case of questions please send email to mary.ietf.barnes at gmail.com
REMINDER: Call for Papers, IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, Vancouver, Canada, July 28, 2012
Call for Papers The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting. More information on the workshop is available at http://www.iab.org/cc-workshop/ This is an invitation-only workshop. Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. If your expertise allows you to write about a range of topics, pick the one topic you think would bring the most value to the workshop. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published. Please use the following Website for submitting your papers: http://iab.org/ccirtc/paper?p=new Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 IPR Policy Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop. Privacy Notice Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings). Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers. There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions. Meeting Venue The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html). Additional details about the meeting venue will be provided to authors of accepted papers. Sponsorship If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! Contact Information In case of questions please send email to mary.ietf.barnes at gmail.com
REMINDER: Call for Papers, IAB/IRTF Congestion Control Workshop
Call for Papers The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting. More information on the workshop is available at http://www.iab.org/cc-workshop/ This is an invitation-only workshop. Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. If your expertise allows you to write about a range of topics, pick the one topic you think would bring the most value to the workshop. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published. Please use the following Website for submitting your papers: http://iab.org/ccirtc/paper?p=new http://iab.org/ccirtc/paper?p=new Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 IPR Policy Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop. Privacy Notice Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings). Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers. There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions. Meeting Venue The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html). Additional details about the meeting venue will be provided to authors of accepted papers. Sponsorship If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! Contact Information In case of questions please send email to mary.ietf.bar...@gmail.com http://www.iab.org/cc-workshop/mary.ietf.bar...@gmail.com
Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada
IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication July 28, 2012 Vancouver, Canada The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/83/index.html http://www.ietf.org/meeting/84/index.html). Participation at the workshop is free of charge. There is no requirement to either register with or attend the IETF-84 meeting that follows the workshop. The workshop organizers would like to foster a discussion on: 1. What are appropriate congestion signals to use for interactive media and data? 2. What existing congestion control algorithms are appropriate for interactive media and data? What properties would be desirable in new congestion control algorithms? 3. Measurement and/or simulations of new congestion signals (e.g., delay-based) and their interaction with existing congestion control mechanisms. 4. What are good available techniques for adjusting sending rates for interactive media and data? What are the limits of those techniques? What properties would be desirable in new techniques? 5. What application-specific considerations have to be taken into account? 6. How can we ensure that real-time communications are well-behaved with respect to other Internet applications while still providing good quality? 7. What should the IETF and/or IRTF do? The organizers seek position papers on any or all of these topics, as well as other topics related to congestion control for interactive realtime media. Every prospective workshop participant must submit a position paper containing a name and an email address. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published. Additional details about the meeting venue will be provided to authors of accepted papers. Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Additional Details Additional details on the workshop as well as the submission process is available at http://www.iab.org/cc-workshop/ Contact To sponsors: If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! In case of questions please send email to mary.ietf.barnes at gmail.com.
Last Call: draft-ietf-dccp-udpencap-10.txt (Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)) to Proposed Standard
The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)' draft-ietf-dccp-udpencap-10.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-05-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 6356 on Coupled Congestion Control for Multipath Transport Protocols
A new Request for Comments is now available in online RFC libraries. RFC 6356 Title: Coupled Congestion Control for Multipath Transport Protocols Author: C. Raiciu, M. Handley, D. Wischik Status: Experimental Stream: IETF Date: October 2011 Mailbox:costin.rai...@cs.pub.ro, m.hand...@cs.ucl.ac.uk, d.wisc...@cs.ucl.ac.uk Pages: 12 Characters: 27961 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mptcp-congestion-07.txt URL:http://www.rfc-editor.org/rfc/rfc6356.txt Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called resource pooling where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community. This document is a product of the Multipath TCP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-mptcp-congestion-05.txt (Coupled Congestion Control for Multipath Transport Protocols) to Experimental RFC
The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'Coupled Congestion Control for Multipath Transport Protocols' draft-ietf-mptcp-congestion-05.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-07-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Informational RFC to be: draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt
The IESG has no problem with the publication of 'Open Research Issues in Internet Congestion Control' draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt as an Informational RFC. The IESG would also like the IRSG to review the comments in the datatracker (https://datatracker.ietf.org/doc/draft-irtf-iccrg-welzl-congestion-control-open-research/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-irtf-iccrg-welzl-congestion-control-open-research/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. Working Group Summary This document represents the work and the consensus of the ICCRG. Personnel Lars Eggert (lars.egg...@nokia.com) has reviewed this document for the IESG. RFC Editor Note (1) Replace beginning of Section 3.5.3 with: 3.5.3 Inelastic Multi-domain Pseudowires Extending pseudo-wires across multiple domains poses specific issues. Pseudowires (PW) [RFC3985] may carry non-TCP data flows (e.g. TDM traffic or Constant Bit Rate (CBR) ATM traffic) over a multi-domain IP network. Structure Agnostic TDM over Packet (SATOP) [RFC4553], Circuit Emulation over Packet Switched Networks (CESoPSN), TDM over IP, are not responsive to congestion control as discussed by [RFC2914] (see also [RFC5033]). The same observation applies to ATM circuit emulating services (CES) interconnecting CBR equipment (e.g. PBX) across a Packet Switched Network (PSN). Moreover, it is not possible to simply reduce the flow rate of a TDM PW or an ATM PW when facing packet loss. Providers can rate control corresponding incoming traffic but they may not be able to detect that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing the traffic temporal properties may not necessarily be supported). This can be illustrated with the following example. (2) Add at the end of Section 3.8.4 Congestion Control in Multi-layered Networks Section 3.5.3 deals with Inelastic Multi-domain Pseudowires (PW), where the characteristics of the Pseudowire itself determines the characteristics of the traffic crossing the multi-domain PSN (and this independently of the characteristics of the traffic carried in the PW). A more complex situation arises when inelastic traffic is carried as part of a Pseudowire (e.g. inelastic traffic over Ethernet PW over PSN) whose edges do not have the means to characterize the properties of the traffic encapsulated into the Ethernet frames. In this case, the problem explained in Section 3.5.3 is not limited to multi-domain Pseudowires but more generally induced by Pseudowire carrying inelastic traffic (over a single- or multi-domain PSN). The problem becomes even more intricated when the Ethernet PW carries both inelastic and elastic traffic. Addressing this issue further comforts our observation that a general framework to efficiently deal with congestion control problems in multi-layer networks is absolutely necessary but without harming its evolvability. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5762 on RTP and the Datagram Congestion Control Protocol (DCCP)
A new Request for Comments is now available in online RFC libraries. RFC 5762 Title: RTP and the Datagram Congestion Control Protocol (DCCP) Author: C. Perkins Status: Standards Track Stream: IETF Date: April 2010 Mailbox:c...@csperkins.org Pages: 16 Characters: 37537 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dccp-rtp-07.txt URL:http://www.rfc-editor.org/rfc/rfc5762.txt The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS TRACK] This document is a product of the Datagram Congestion Control Protocol Working Group of the IETF. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5783 on Congestion Control in the RFC Series
A new Request for Comments is now available in online RFC libraries. RFC 5783 Title: Congestion Control in the RFC Series Author: M. Welzl, W. Eddy Status: Informational Date: February 2010 Mailbox:mich...@ifi.uio.no, w...@mti-systems.com Pages: 28 Characters: 68231 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-iccrg-cc-rfcs-07.txt URL:http://www.rfc-editor.org/rfc/rfc5783.txt This document is an informational snapshot taken by the IRTF's Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5690 on Adding Acknowledgement Congestion Control to TCP
A new Request for Comments is now available in online RFC libraries. RFC 5690 Title: Adding Acknowledgement Congestion Control to TCP Author: S. Floyd, A. Arcia, D. Ros, J. Iyengar Status: Informational Date: February 2010 Mailbox:fl...@icir.org, ae.ar...@telecom-bretagne.eu, david@telecom-bretagne.eu, jiyen...@fandm.edu Pages: 33 Characters: 83437 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-floyd-tcpm-ackcc-06.txt URL:http://www.rfc-editor.org/rfc/rfc5690.txt This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5595 on The Datagram Congestion Control Protocol (DCCP) Service Codes
A new Request for Comments is now available in online RFC libraries. RFC 5595 Title: The Datagram Congestion Control Protocol (DCCP) Service Codes Author: G. Fairhurst Status: Standards Track Date: September 2009 Mailbox:go...@erg.abdn.ac.uk Pages: 19 Characters: 44803 Updates:RFC4340 I-D Tag:draft-ietf-dccp-serv-codes-11.txt URL:http://www.rfc-editor.org/rfc/rfc5595.txt This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS TRACK] This document is a product of the Datagram Congestion Control Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 150, RFC 5597 on Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
A new Request for Comments is now available in online RFC libraries. BCP 150 RFC 5597 Title: Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol Author: R. Denis-Courmont Status: Best Current Practice Date: September 2009 Mailbox:r...@videolan.org Pages: 9 Characters: 18933 See Also: BCP00150 I-D Tag:draft-ietf-behave-dccp-05.txt URL:http://www.rfc-editor.org/rfc/rfc5597.txt This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5681 on TCP Congestion Control
A new Request for Comments is now available in online RFC libraries. RFC 5681 Title: TCP Congestion Control Author: M. Allman, V. Paxson, E. Blanton Status: Standards Track Date: September 2009 Mailbox:mall...@icir.org, v...@icir.org, eblan...@cs.purdue.edu Pages: 18 Characters: 44339 Obsoletes: RFC2581 I-D Tag:draft-ietf-tcpm-rfc2581bis-07.txt URL:http://www.rfc-editor.org/rfc/rfc5681.txt This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5634 on Quick-Start for the Datagram Congestion Control Protocol (DCCP)
A new Request for Comments is now available in online RFC libraries. RFC 5634 Title: Quick-Start for the Datagram Congestion Control Protocol (DCCP) Author: G. Fairhurst, A. Sathiaseelan Status: Experimental Date: August 2009 Mailbox:go...@erg.abdn.ac.uk, arj...@erg.abdn.ac.uk Pages: 22 Characters: 52726 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dccp-quickstart-05.txt URL:http://www.rfc-editor.org/rfc/rfc5634.txt This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Datagram Congestion Control Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'TCP Congestion Control' to Draft Standard
The IESG has approved the following document: - 'TCP Congestion Control ' draft-ietf-tcpm-rfc2581bis-07.txt as a Draft Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-07.txt Technical Summary The congestion control algorithms described in RFC 2581 are widely implemented and used. This document clarifies some specific points that have created questions for implementers in the past. Working Group Summary The working group saw the need for this document based on a small number of commonly recurring questions about what is meant by certain wordings in RFC2581. The working group was easily able to agree on the clarifications that this document provides. Document Quality The document was reviewed for quality by a large number of TCPM WG members. Personnel Wes Eddy (wesley.m.e...@nasa.gov) is the document shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Quick-Start for Datagram Congestion Control Protocol (DCCP)' to Experimental RFC
The IESG has approved the following document: - 'Quick-Start for Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-quickstart-05.txt as an Experimental RFC This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-quickstart-05.txt Technical Summary This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). The document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3 and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). Working Group Summary The document has been produced and reviewed by the DCCP working group and the WG is in agreement to publish this document. A copy of the WG last-call note was also sent to the TSVWG mailing list. Document Quality There are no implementations known of this specification, apart from ns-2 simulations. The key authors of the original Quick-Start RFC 4782 have also reviewed the earlier version of the document, and the document has addressed their comments. Personnel The Document shepherd is Pasi Sarolahti (pasi.sarola...@iki.fi). The Responsible Area Director is Lars Eggert (lars.egg...@nokia.com). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dccp-ccid4 (Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)) to Experimental RFC
The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) ' draft-ietf-dccp-ccid4-04.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dccp-ccid4-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16485rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dccp-quickstart (Quick-Start for Datagram Congestion Control Protocol (DCCP)) to Experimental RFC
The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'Quick-Start for Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-quickstart-05.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dccp-quickstart-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17359rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-tcpm-rfc2581bis (TCP Congestion Control) to Draft Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Congestion Control ' draft-ietf-tcpm-rfc2581bis-05.txt as a Draft Standard The implementation report supporting the advancement to Draft Standard is at: http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-05.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14183rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol' to BCP
The IESG has approved the following document: - 'Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol ' draft-ietf-behave-dccp-05.txt as a BCP This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-dccp-05.txt Technical Summary This document defines a set of requirements for DCCP-capable NATs that would allow certain applications, such as streaming applications to operate consistently. Working Group Summary There is consensus in the working group to publish this document. Document Quality There are no known implementations. This was WG last called and reviewed by the DCCP WG. There are two normative reference to documents (draft-ietf-behave-nat-icmp and draft-ietf-dccp-simul-open) not yet published but that doesn't preclude progressing this document until it ends up in the RFC-editor's queue. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5238 on Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)
A new Request for Comments is now available in online RFC libraries. RFC 5238 Title: Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) Author: T. Phelan Status: Standards Track Date: May 2008 Mailbox:[EMAIL PROTECTED] Pages: 10 Characters: 24394 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dccp-dtls-06.txt URL:http://www.rfc-editor.org/rfc/rfc5238.txt This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS TRACK] This document is a product of the Datagram Congestion Control Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)' to Proposed Standard
The IESG has approved the following document: - 'Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-dtls-06.txt as a Proposed Standard This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-dtls-06.txt Technical Summary This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for datagram protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. Working Group Summary This document is a product of the DCCP working group. The document is expected to apply to the use of current and future versions of DTLS over the DCCP transport service. Document Quality The DCCP WG has reached consensus that this document is ready for publication, and recommends publication on the IETF Standards Track. Personnel Gorry Fairhurst ([EMAIL PROTECTED]) was the Document Shepherd. Lars Eggert ([EMAIL PROTECTED]) has reviewed this document for the IESG. RFC Editor Note Change in the abstract: OLD TEXT: This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for datagram protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. NEW TEXT: This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. Change in Section 1, first paragraph: OLD TEXT: This document specifies how to use Datagram Transport Layer Security (DTLS), as specified in [RFC4347], over the Datagram Congestion Control Protocol (DCCP), as specified in [RFC4340]. NEW TEXT: This document specifies how to carry application payloads with Datagram Transport Layer Security (DTLS), as specified in [RFC4347], in the Datagram Congestion Control Protocol (DCCP), as specified in [RFC4340]. Change in Section 1, last paragraph: OLD TEXT: The combination of DTLS and DCCP will offer transport security capabilities to DCCP users similar to those available for TCP, UDP and SCTP. NEW TEXT: The combination of DTLS and DCCP will offer transport security capabilities to applications using DCCP similar to those available for TCP, UDP and SCTP. Replace one paragraph of text in Section 3 as follows: OLD TEXT: The approach here is very straightforward -- DTLS records are transmitted in the Application Data fields of DCCP-Data and DCCP-DataAck packets (in the rest of the document assume that DCCP-Data packet means DCCP-Data or DCCP-DataAck packet). Multiple DTLS records MAY be sent in one DCCP-Data packet, as long as the resulting packet is within the Path Maximum Transfer Unit (PMTU) currently in force for normal data packets, if the Don't Fragment (DF) bit is being used, or within the current DCCP maximum packet size if the DF bit is not being used (see section 3.5 for more information on PMTU Discovery). A single DTLS record MUST be fully contained in a single DCCP-Data packet; it MUST NOT be split over multiple packets. NEW TEXT: The approach here is very straightforward -- DTLS records are transmitted in the Application Data fields of DCCP-Data and DCCP-DataAck packets (in the rest of the document assume that DCCP-Data packet means DCCP-Data or DCCP-DataAck packet). Multiple DTLS records MAY be sent in one DCCP-Data packet, as long as the resulting packet is within the Path Maximum Transfer Unit (PMTU) currently in force for normal data packets, if fragmentation is not allowed (the Don't Fragment (DF) bit is set for IPv4 or no fragmentation extension headers are being used for IPv6), or within the current DCCP maximum packet size if fragmentation is allowed (see Section 3.5 for more information on PMTU Discovery). A single DTLS record MUST be fully contained in a single DCCP-Data packet; it MUST NOT be split over multiple
RFC 5166 on Metrics for the Evaluation of Congestion Control Mechanisms
A new Request for Comments is now available in online RFC libraries. RFC 5166 Title: Metrics for the Evaluation of Congestion Control Mechanisms Author: S. Floyd, Ed. Status: Informational Date: March 2008 Mailbox:[EMAIL PROTECTED] Pages: 23 Characters: 53609 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-tmrg-metrics-11.txt URL:http://www.rfc-editor.org/rfc/rfc5166.txt This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols. This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community. This document is a product of the IRTF Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dccp-dtls (Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)) to Proposed Standard
The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-dtls-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-03-25. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dccp-dtls-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16007rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce
ION Announcement: Experimental Specification of New Congestion Control Algorithms
A new IETF Operational Note (ION) is now available in online: Name: ion-tsv-alt-cc Title: Experimental Specification of New Congestion Control Algorithms URL: http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt This ION was approved by the IESG on July 5, 2007. This document describes the process that the IETF transport area directors employ when new congestion control algorithms that differ significantly from currently-published IETF standards are brought to the IETF for specification and publication as Experimental RFCs. Discussion forum: [EMAIL PROTECTED] ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
BCP 133, RFC 5033 on Specifying New Congestion Control Algorithms
A new Request for Comments is now available in online RFC libraries. BCP 133 RFC 5033 Title: Specifying New Congestion Control Algorithms Author: S. Floyd, M. Allman Status: Best Current Practice Date: August 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 10 Characters: 23469 Updates: See-Also: BCP0133 I-D Tag:draft-ietf-tsvwg-cc-alt-04.txt URL:http://www.rfc-editor.org/rfc/rfc5033.txt The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Transport Area Working Group Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RTP and the Datagram Congestion Control Protocol (DCCP)' to Proposed Standard
The IESG has approved the following document: - 'RTP and the Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-rtp-07.txt as a Proposed Standard This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-07.txt Technical Summary The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. Working Group Summary The consensus within the DCCP WG to publish this document as a draft standard RFC is strong. Protocol Quality The document is clear and the mechanisms involved are fairly straight-forward and simple. There is believed to be at least one implementation in progress. Personnel Tom Phelan ([EMAIL PROTECTED]) was the document shepherd. Lars Eggert ([EMAIL PROTECTED]) reviewed this document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Specifying New Congestion Control Algorithms' to BCP
The IESG has approved the following document: - 'Specifying New Congestion Control Algorithms ' draft-ietf-tsvwg-cc-alt-04.txt as a BCP This document is the product of the Transport Area Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt Technical Summary The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. Working Group Summary The WG consensus on this document was clear, but not overwhelmingly strong. Protocol Quality The document has been presented to the WG during several IETF meetings and has been reviewed by a number of key WG members. It has also been discussed in the IRTF's ICCRG and the wider research community. Personnel Lars Eggert ([EMAIL PROTECTED]) was the document shepherd and also reviewed this document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dccp-rtp (RTP and the Datagram Congestion Control Protocol (DCCP)) to Proposed Standard
The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'RTP and the Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-rtp-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-06-20. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dccp-rtp-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15015rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
On Tue, 29 May 2007, Mark Allman wrote: Or do you mean that the proposers should do everything guidelines (2), (5), (6) and (7) say, but shortcomings in the results of these guidelines (e.g., proposal being only slightly more troublesome than TCP) should not block the approval for widespread deployment in the global Internet. Yes. And, in re-reading the text I think it is clear. I really can't untangle your comments in this area. If you have specific suggestions for the text, please send them along. -03 has: For other guidelines, i.e., (2), (5), (6), and (7), evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. if the above is what you mean (and a proposer must really go through everything you list, e.g., all the difficult environments as well), it should be explicit, e.g.: For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. My problem with existing text is that the referred guidelines use wording should do Is it a must do or may do or something in between? It should be more explicit. Text proposal above interprets the shoulds as musts. 4) The first evaluation criteria also includes We also note that this guideline does not constrain the fairness offered for non-best-effort traffic. I don't understand your point here. All we are saying is that if---by some means---we know that some flow is not best effort then it can be subjected to some other criteria then it need not be constrained by the guideline. What I try to say is that I can't figure out how operationally and practically this could be achieved. Do you have examples in mind how how this could apply in some specific scenario? If not -- and it isn't a practical concern right now -- maybe we should not overengineer the BCP to address best-effort vs non-best-effort at all. We didn't overengineer anything. We just said that the guideline doesn't apply to non-BE cases. I can't understand your point here at all. It is a simple statement of document scope. Let's say I propose an informational RFC on congestion control and say that it only applies to non-BE traffic. I don't have to make any of the evaluations or analysis required by this draft. What's the procedure for non-BE congestion control agorithms? I note that Lars's ION does not mention that case. In case there is no process to define non-BE congestion control mechanisms at all (and the response would be sorry, we don't support that), I have no problem. In case there is some process with a lower bar, I'd have a problem, because it would be possible to avoid the loops you have jump through defined in this document by saying the CC algorithm applies to non-BE traffic only, but in practice it would be end up deployed for BE traffic as well. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. Looks OK to me. I have incorporated it, modulo comments from Sally. As for the non-BE stuff: This document is a no-op. But, why is that an issue? The IETF would have to grapple with the non-BE case just as it does today (i.e., without a set of guidelines). This one document does not need to solve all the world's problems. If you want to write a document about how the IETF should handle non-BE congestion control proposals, I think that'd be fine. And, again, I am not hearing outcry on this point so I think the document is fine (even if the consensus on this one point is not completely 'smooth'). Thanks, allman pgpZ20qD5vV8W.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
