WG Action: Formed Machine Learning for Audio Coding (mlcodec)
A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chair. Machine Learning for Audio Coding (mlcodec) --- Current status: Proposed WG Chairs: Timothy Terriberry Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Mailing list: Address: mlco...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/mlcodec/ Archive: https://mailarchive.ietf.org/arch/browse/mlcodec/ Group page: https://datatracker.ietf.org/group/mlcodec/ Charter: https://datatracker.ietf.org/doc/charter-ietf-mlcodec/ Problem Statement The Opus codec (RFC 6716) was adopted by the IETF in 2012. Since then, speech and audio processing technology has made significant progress, thanks in large part to deep learning techniques. It is desirable to update the existing Opus codec to benefit from recent advances without breaking compatibility with RFC 6716. Opus has achieved a wide degree of interoperability by using in-band signaling to avoid negotiation failure. Implementing new coding technology within Opus would allow incremental compatible deployment of the updated specification, while preserving interoperability with the existing billions of Opus-enabled devices. In doing so, we wish to retain the original qualities that drove the original Opus development to develop codecs that (quoting from codec WG charter): 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. Objectives The goals of this working group are: 1) Improving the robustness to packet loss of Opus through efficient redundancy transmission 2) Improving the speech coding quality at low bitrates 3) Improving the music coding quality at low bitrates The working group may also consider other improvements to Opus. The group will only consider solutions that result in bitstreams that are forwards and backwards compatible with RFC6716, and thus decodable by any decoder. Although it is likely that machine learning will be required to meet the objectives above, classical solutions will also be considered if they can achieve similar performance. As was the case with the original codec WG, this work will primarily focus on interactive, real-time applications over the Internet and will ensure interoperability with existing IETF real-time protocols, including RTP, SIP/SDP, and WebRTC. Given the widespread deployment of WebRTC, ensuring that the work improves WebRTC experience is of particular importance. Other applications, such as non-real-time streaming will be considered too, but only so long as their requirements do not interfere with those of real-time applications. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, consistent with BCP 78 and BCP 79, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. Deliverables 1. A specification for a generic Opus extension mechanism that can be used not only for the other proposed deliverables, but can also sustain further extensions to Opus in the future. This document shall be a Proposed Standard document. 2. A specification for coding large amounts of very low bitrate redundancy information for the purpose of significantly improving the robustness of Opus to bursts of packet loss. This document shall be a Proposed Standard document. 3. A specification for improving the quality of SILK- and hybrid-coded speech through decoder changes, with and without side information provided by the encoder. This will be done in a way that does not affect interoperability between original and extended implementations. This document shall be a Proposed Standard document. 4. A specification for improving the quality of CELT-coded audio (both speech and music) through decoder changes, with and without side information provided by the encoder. This will be done in a way that does not affect interoperability between original and extended implementations. This document shall be a Proposed Standard document. Milestones: Dec 2023 - Submit generic Opus extension mechanism to the IESG as Proposed Standard. Mar 2024 - Submit specification for Opus resiliency against packet loss to the IESG as Proposed Standard. Jun 2024 - Submit specification for improving the quality SILK- and hybrid-coded speech to the IESG as Proposed Standard. Sep 2024 - Sunmit specification for improving the quality of CELT-coded audio to the IESG as Proposed Standard.
Protocol Action: 'Subject Identifiers for Security Event Tokens' to Proposed Standard (draft-ietf-secevent-subject-identifiers-18.txt)
The IESG has approved the following document: - 'Subject Identifiers for Security Event Tokens' (draft-ietf-secevent-subject-identifiers-18.txt) as Proposed Standard This document is the product of the Security Events Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/ Technical Summary Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects. It also defines a registry for defining and allocating names for such formats, as well as the sub_id JSON Web Token (JWT) claim. Working Group Summary There was nothing notable in the WG process beyond the long dormancy this document had. Document Quality This is a dependency of the GNAP WG, and GNAP participants have been involved in the later development stages of this draft. Personnel - Document Shepherd: Yaron Sheffer - Responsible AD: Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
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
