The real-time interactive streaming revolution kicked into high gear at the recent IBC show in Amsterdam, fueled by intensifying activity around the emerging Media-over-QUIC (MOQ) standard and an outpouring of unrelated innovations by multiple suppliers.
With myriad paths now open to a market hungry for real-time connectivity, competing vendor messages mixed with much confusion over who is doing what lent an air of chaos typical of any major sea change in how things are done on the internet. But the momentum behind MOQ suggested that whatever upheaval lies immediately ahead, the International Engineering Task Force’s standards-based approach will become the new norm in video usage before too long.
Two of the more significant developments coming to light at the September gathering in Amsterdam that could hasten that outcome involved initiation of the OpenMOQ Consortium as an arena for fostering open-source development among vendors developing MOQ streaming software and the launch by CDN operator Cloudflare of the first global server footprint for activating MOQ proofs of concept in the real world.
It was also notable that Vindral, provider of a global CDN service supporting managed and DIY low-latency streaming over the past six years or so, has now implemented a pre-standardized version of MOQ as its default transport mode. And there were signs that some current providers of real-time interactive streaming (RTIS) platforms making use of WebRTC or other protocols will soon get behind early phase testing of the MOQ waters.
But, for now at least, most RTIS suppliers as well as those anchored in the HTTP streaming world with HLS and MPEG-DASH were voicing a more passive wait-and-see stance on MOQ. Meanwhile, consensus that the status quo is way off the mark of where things need to be has reached a flashpoint across the video streaming ecosystem.
As we heard repeatedly at IBC, the world wants a ubiquitously available two-way superhighway over which video flows in any direction at any scale with latencies low enough to prevent perceived delay between source and receiver. And it must be done at quality levels matching the best one-way video experiences, i.e., 4K and soon 8K with HDR brilliance.
That’s a long way from where we are today, notwithstanding the availability of a few options on offer from individual suppliers who can massively scale RTIS at resolutions as high as HD 1080p and, in some cases, are knocking on the 4K UHD door. What’s needed is a standardized universally adopted approach that everybody can readily connect to, just like they do with Hypertext Transfer Protocol (HTTP)-based streaming today.
The MOQ Transport Solution
Seen in that light amid surging demand for a solution, MOQ seems to be the most likely course to success. First, though, there are still some issues to be resolved in the push to finalize the underlying MOQ Transport (MOQT) protocol, now in its 14th draft. Will Law, chief architect for the cloud technology group at Akamai and a leader in the IETF’s MOQ initiative, was only half joking when he invited the audience at his recent talk on MOQ at the RTC.ON developers conference in Kraków to “watch sausage being made in all its glory” at the next IETF meeting.
But MOQ isn’t being built from scratch. The transport foundation relies on the widely used QUIC protocol, which is now the transport standard used with HTTP/3, the latest version of the dominant server system used in streaming.
By relying on the User Datagram Protocol (UDP), an internet communications technology that uses datagrams (packets consisting of headers and payloads) to send messages to destinations without negotiating a connection or reacting when packets are dropped, QUIC sets up the traffic flow much faster than can be done with back-and-forth messaging used by the still dominant Transmission Control Protocol (TCP). Equally important, it avoids the buffering associated with retransmitting dropped packets that occurs with TCP.
Because the connectionless approach allows multiplexing of independent concurrent transmissions of the stream within a single connection, QUIC, more often than not, ensures that when packets in one stream are blocked, those packets still get through in contrast to lengthy TCP flows that can be blocked awaiting retransmission of dropped head-of-line packets. Adding to robustness, the IETF has added forward-error-correction (FEC) extensions that enable “erasure control” by sending redundant data receivers can access to recover lost packets. The overall result is reliable performance with much less latency, which can be exploited with use of multicasting in mass streaming environments.
Augmenting ease of use, MOQT can be used with a WebTransport layer running between QUIC and MOQT to facilitate compatibility with browsers. WebTransport, developed by the World Wide Web Consortium (W3C) with expectations that it will be finalized as a standard by YE 2025, is a web API that enables the QUIC/UDP-based HTTP/3 protocol to be used in bidirectional low-latency transport.
When used with MOQT, WebTransport doesn’t incorporate the entire HTTP stack, Law says. It’s “a thin layer of HTTP that sits on top of QUIC,” he explains. “That’s all it is, but it’s very useful, because it looks like you’re connecting to an HTTP/3 resource from the outside. It essentially gives you the QUIC connection, and then HTTP is gone, and I just have my QUIC stream and my QUIC datagrams.”
Critically, QUIC enables a publish/subscribe approach to streaming, which avoids the complex request-response method used with traditional HTTP streaming. Whereas a one-hour video streamed over HLS or DASH entails thousands of client requests for short sections of video, with MOQ, once a user selects a tendered media stream from a publisher, the stream transmits in its entirety or until the user quits the stream.
The fundamental building blocks in MOQT are known as objects, i.e., packets consisting of headers and messages that can comprise the streamed content payloads going to end users or the control object payloads that direct set-up and how the stream is to be used one-way or bidirectionally. Objects are assigned linearly precise positions in sequences or groups typically bounded by I frames that make up the streamed tracks flowing over MOQT.
Every object is associated with a specific series of groups comprising a track. Object-track ties rely on a naming system hidden behind whatever branding a streamer uses, which allows subscribers clicking on those links to join a live session at the outset or at any juncture between groups in the flow.
While the MOQT objects bear A/V and data payloads, the encoding, encryption, framing and other mechanisms comprising the media layer are decoupled from transport, which maximizes flexibility in streamers’ use of codecs, DRM, watermarking, approaches to advertising and feature personalization, and other components of their applications. As Law notes, the decoupling allows CDNs to deploy MOQ Transport as a service supporting all MOQ-compatible streaming formats, much as HTTP supports HLS, DASH and other formats.
“We have just a pipe, a highly efficient pipe between a client and a server,” he says. “So it’s quite flexible.”
At the same time, there’s a tremendous amount of functionality built into the transport layer, including some things that are baked in like relay servers, track structures and transport communications security embodied in encryption mandated by the QUIC standard. And there are other mechanisms available optionally to enhance flexibility in the use of transport.
For example, groups can be divided into subgroups running in parallel to create multiple transport options related to a particular track, as when blockage of a stream delivered at 30 frames per second in the presence of heavy congestion can be avoided with reversion to a 15fps flow. Most important, there’s a lot of functional flexibility built into the relay system, including whether caching is used with relay servers, and, if it is, what the cache storage is used for.
The Vital Role of Relay Servers
Relay servers are points of connection from the originating source of content at the ingestion into MOQT through to end users in arrays comprising a delivery network analogous to today’s CDNs. Each relay is a point of termination with visibility into MOQ object metadata that enables it to act simultaneously as a subscriber to tracks from upstream and as a publisher forwarding tracks downstream to other relays or end users. (The payload segment of the object byte string remains encrypted and untouched by relay processing.)
The configuration allows any given stream to be fanned out from a single source to any number of end users wherever they might be, all in accord with the rights authorization and authentications mandated by the control objects, as well as timestamp correlation across all streams in instances where synchronized reception is vital to the use case.
As explained by Law, relay servers play a major role in maintaining high levels of performance that complement the robustness supported by QUIC. This has to do with hiccups in transmissions where the disruption is no longer about a dropped packet on a sub-stream moving over a particular router hop. With any breakdown in electronic processing in datacenters or at any point in the international networking grid, even with failsafe redundancy, there’s at least a split-second diminution in affected streams’ quality that can’t be avoided by QUIC mechanisms alone. “With real time, you’re going to get perturbations in throughput,” Law notes. “That’s a fact of life with the internet, especially over mobile connections, less so over fiber, but they occur. And when your latency is very low, you have no buffer in your player to protect the player from these perturbations. So you’ll see that as either a stutter or a rebuffering. It’ll be a very brief one, but it will still be there.” If real-time delivery is top priority, people will have to live with these occasional glitches. But if top-of-line quality is the priority, then alternatives supported by MOQ caches might be the better option. With MoQ, “we can make available different latency regimes on the same stream,” Law notes.
Glass-to-glass tunable latencies with variable levels of buffering protection can range from real-time at 200-400ms to what Law calls “interactive live” for use in sports betting, online casino gambling, banking and similar applications at 2 seconds, to “conservative live” with persistent HD, 4K or, eventually, 8K quality at 5 seconds.
Moreover, depending on how MOQ-ready CDNs are designed, MOQ can also support recording live content for short-term replay and catchup and long-term storage for VOD archives and cloud DVR applications. “VOD just means my cache is big enough to hold stuff that was live a while ago,” Law says.
Media Layer and Other Initiatives
Paralleling MOQT development, there are other IETF initiatives underway that are aimed at creating a practical operating environment for the transport protocol, all of which are under the umbrella Law wants to be known as MOQ without referencing it as an acronym for Media over QUIC, much as QUIC itself is now considered a standalone name rather than the acronym it once was for Quick UDP Internet Connections as originally posited by its developers at Google.
One MOQ-related protocol now under development is the streaming format known as WARP, another name shorn of acronym references, which offers a usable example of how content can be encoded, encrypted and packaged in MOQ payloads for commercial video streaming services. As Law notes, the decoupling of transport from media formats and codecs allows CDNs to deploy MOQ Transport as a service and all MOQ-compatible streaming formats, much as HTTP supports HLS, DASH and other formats.
“There’s no limit to the number of streaming formats that can use transport,” he says. “We want CDNs to deploy this at scale and globally as a service where I can bring my applications and plug them in and just use it.”
It’s possible to create application-specific streaming formats that may or may not involve video, he adds, such as might be used for chat services, autonomous vehicle operations, industrial IoT or smart city management. Notably, open-source based development of streaming formats as a spur to the use of MOQ is one of the goals set for the still-forming OpenMOQ Consortium, which as an initiative independent of IETF instigated by Akamai has drawn publicly acknowledged support from Oracle, Cisco, YouTube, Synamedia, and CDN77 along with the interest of many other entities.
“Cisco is very interested in MOQ,” Law says. “They’re building out the next-gen Webex client to use it.” This will enable video chatting depending on users’ choices of codecs at HD 1080p or, if the user has the bandwidth, 4K UHD with full-screen display like one would get currently with an enterprise premium teleconferencing service.
As for other MOQ-related IETF initiatives, Low Overhead Media Container (LOC) specifies a lighter weight approach to stream layer packaging that’s targeted to align with media formats using WebCodecs, a standard defining interfaces with encoders and decoders used in internet communications. There’s also CAT-4-MOQT, which defines how tokens can be used to prevent unauthorized access to MOQ networks and use cases, and CARP, which allows content packaged in the Common Media Application Framework (CMAF) for conventional HTTP streaming to be used in WARP-formatted streams over MOQ.
Prospects for Costly MOQ Infrastructure Buildout
The very good news coming out of this extraordinary brain dump from the IETF stream squad is that, based on demos, documentation and our conversations at IBC, there’s no reason to doubt the sausage making will lead to a much-needed standard sometime in 2026 that’s capable of unleashing the pent-up RTIS demand at world-changing scale. So now the overarching question is, how soon will CDN operators deem MOQ demand sufficient to merit investing in the multi-CDN infrastructure that will be needed to provide a ubiquitous alternative to HTTP on commodity servers running in datacenters worldwide?
It won’t come cheap, given the fact that MOQ is not compatible with CDNs solely tuned to HTTP streaming. Existing CDN operators will have to dedicate additional server resources to running origin and relay applications of MOQ software, much as anyone has to do when mounting WebRTC-based RTIS infrastructures. In terms of creating the support infrastructure, “WebRTC and MOQ are cost equivalent,” Law says.
But at least the abundance of distributed cloud computing resources provided by Akamai and other hyperscalers worldwide should make it easy for cloud-based CDNs to tap the resources they need to expand into MOQ streaming. Of course, the hunger for AI processing support from AI-optimized GPUs could overwhelm the rapidly expanding datacenter footprint, but the returns on the rest of the CPU and GPU resource base seem sure to keep that side thriving, especially if it means the opportunity to support a transformed approach to how people engage in the networked economy.
Based on what’s been demonstrated so far, the MOQ infrastructure investments may not be long in coming.
As described by Cloudflare systems engineers Mike English and Renan Dincer, Cloudflare has launched the world’s first MOQ relay network running in compliance with MOQT Draft 7 on all its datacenter servers in over 330 cities. “We're joining Meta, Google, Cisco, and others in building implementations that work seamlessly together, creating a shared foundation for the next generation of real-time applications on the Internet,” they said in their August blog. “We want developers to start building with MoQ today.”
Toward that end they’ve made the MOQ infrastructure available for testing use cases at any scale free of charge. While the system is based on an outdated MOQT draft, users are averaging end-to-end latencies at 368ms.
As Law says, “Not bad for a POC.”
With myriad paths now open to a market hungry for real-time connectivity, competing vendor messages mixed with much confusion over who is doing what lent an air of chaos typical of any major sea change in how things are done on the internet. But the momentum behind MOQ suggested that whatever upheaval lies immediately ahead, the International Engineering Task Force’s standards-based approach will become the new norm in video usage before too long.
Two of the more significant developments coming to light at the September gathering in Amsterdam that could hasten that outcome involved initiation of the OpenMOQ Consortium as an arena for fostering open-source development among vendors developing MOQ streaming software and the launch by CDN operator Cloudflare of the first global server footprint for activating MOQ proofs of concept in the real world.
It was also notable that Vindral, provider of a global CDN service supporting managed and DIY low-latency streaming over the past six years or so, has now implemented a pre-standardized version of MOQ as its default transport mode. And there were signs that some current providers of real-time interactive streaming (RTIS) platforms making use of WebRTC or other protocols will soon get behind early phase testing of the MOQ waters.
But, for now at least, most RTIS suppliers as well as those anchored in the HTTP streaming world with HLS and MPEG-DASH were voicing a more passive wait-and-see stance on MOQ. Meanwhile, consensus that the status quo is way off the mark of where things need to be has reached a flashpoint across the video streaming ecosystem.
As we heard repeatedly at IBC, the world wants a ubiquitously available two-way superhighway over which video flows in any direction at any scale with latencies low enough to prevent perceived delay between source and receiver. And it must be done at quality levels matching the best one-way video experiences, i.e., 4K and soon 8K with HDR brilliance.
That’s a long way from where we are today, notwithstanding the availability of a few options on offer from individual suppliers who can massively scale RTIS at resolutions as high as HD 1080p and, in some cases, are knocking on the 4K UHD door. What’s needed is a standardized universally adopted approach that everybody can readily connect to, just like they do with Hypertext Transfer Protocol (HTTP)-based streaming today.
Seen in that light amid surging demand for a solution, MOQ seems to be the most likely course to success. First, though, there are still some issues to be resolved in the push to finalize the underlying MOQ Transport (MOQT) protocol, now in its 14th draft. Will Law, chief architect for the cloud technology group at Akamai and a leader in the IETF’s MOQ initiative, was only half joking when he invited the audience at his recent talk on MOQ at the RTC.ON developers conference in Kraków to “watch sausage being made in all its glory” at the next IETF meeting.
But MOQ isn’t being built from scratch. The transport foundation relies on the widely used QUIC protocol, which is now the transport standard used with HTTP/3, the latest version of the dominant server system used in streaming.
By relying on the User Datagram Protocol (UDP), an internet communications technology that uses datagrams (packets consisting of headers and payloads) to send messages to destinations without negotiating a connection or reacting when packets are dropped, QUIC sets up the traffic flow much faster than can be done with back-and-forth messaging used by the still dominant Transmission Control Protocol (TCP). Equally important, it avoids the buffering associated with retransmitting dropped packets that occurs with TCP.
Because the connectionless approach allows multiplexing of independent concurrent transmissions of the stream within a single connection, QUIC, more often than not, ensures that when packets in one stream are blocked, those packets still get through in contrast to lengthy TCP flows that can be blocked awaiting retransmission of dropped head-of-line packets. Adding to robustness, the IETF has added forward-error-correction (FEC) extensions that enable “erasure control” by sending redundant data receivers can access to recover lost packets. The overall result is reliable performance with much less latency, which can be exploited with use of multicasting in mass streaming environments.
Augmenting ease of use, MOQT can be used with a WebTransport layer running between QUIC and MOQT to facilitate compatibility with browsers. WebTransport, developed by the World Wide Web Consortium (W3C) with expectations that it will be finalized as a standard by YE 2025, is a web API that enables the QUIC/UDP-based HTTP/3 protocol to be used in bidirectional low-latency transport.
When used with MOQT, WebTransport doesn’t incorporate the entire HTTP stack, Law says. It’s “a thin layer of HTTP that sits on top of QUIC,” he explains. “That’s all it is, but it’s very useful, because it looks like you’re connecting to an HTTP/3 resource from the outside. It essentially gives you the QUIC connection, and then HTTP is gone, and I just have my QUIC stream and my QUIC datagrams.”
Critically, QUIC enables a publish/subscribe approach to streaming, which avoids the complex request-response method used with traditional HTTP streaming. Whereas a one-hour video streamed over HLS or DASH entails thousands of client requests for short sections of video, with MOQ, once a user selects a tendered media stream from a publisher, the stream transmits in its entirety or until the user quits the stream.
The fundamental building blocks in MOQT are known as objects, i.e., packets consisting of headers and messages that can comprise the streamed content payloads going to end users or the control object payloads that direct set-up and how the stream is to be used one-way or bidirectionally. Objects are assigned linearly precise positions in sequences or groups typically bounded by I frames that make up the streamed tracks flowing over MOQT.
Every object is associated with a specific series of groups comprising a track. Object-track ties rely on a naming system hidden behind whatever branding a streamer uses, which allows subscribers clicking on those links to join a live session at the outset or at any juncture between groups in the flow.
While the MOQT objects bear A/V and data payloads, the encoding, encryption, framing and other mechanisms comprising the media layer are decoupled from transport, which maximizes flexibility in streamers’ use of codecs, DRM, watermarking, approaches to advertising and feature personalization, and other components of their applications. As Law notes, the decoupling allows CDNs to deploy MOQ Transport as a service supporting all MOQ-compatible streaming formats, much as HTTP supports HLS, DASH and other formats.
“We have just a pipe, a highly efficient pipe between a client and a server,” he says. “So it’s quite flexible.”
At the same time, there’s a tremendous amount of functionality built into the transport layer, including some things that are baked in like relay servers, track structures and transport communications security embodied in encryption mandated by the QUIC standard. And there are other mechanisms available optionally to enhance flexibility in the use of transport.
For example, groups can be divided into subgroups running in parallel to create multiple transport options related to a particular track, as when blockage of a stream delivered at 30 frames per second in the presence of heavy congestion can be avoided with reversion to a 15fps flow. Most important, there’s a lot of functional flexibility built into the relay system, including whether caching is used with relay servers, and, if it is, what the cache storage is used for.
Relay servers are points of connection from the originating source of content at the ingestion into MOQT through to end users in arrays comprising a delivery network analogous to today’s CDNs. Each relay is a point of termination with visibility into MOQ object metadata that enables it to act simultaneously as a subscriber to tracks from upstream and as a publisher forwarding tracks downstream to other relays or end users. (The payload segment of the object byte string remains encrypted and untouched by relay processing.)
The configuration allows any given stream to be fanned out from a single source to any number of end users wherever they might be, all in accord with the rights authorization and authentications mandated by the control objects, as well as timestamp correlation across all streams in instances where synchronized reception is vital to the use case.
As explained by Law, relay servers play a major role in maintaining high levels of performance that complement the robustness supported by QUIC. This has to do with hiccups in transmissions where the disruption is no longer about a dropped packet on a sub-stream moving over a particular router hop. With any breakdown in electronic processing in datacenters or at any point in the international networking grid, even with failsafe redundancy, there’s at least a split-second diminution in affected streams’ quality that can’t be avoided by QUIC mechanisms alone. “With real time, you’re going to get perturbations in throughput,” Law notes. “That’s a fact of life with the internet, especially over mobile connections, less so over fiber, but they occur. And when your latency is very low, you have no buffer in your player to protect the player from these perturbations. So you’ll see that as either a stutter or a rebuffering. It’ll be a very brief one, but it will still be there.” If real-time delivery is top priority, people will have to live with these occasional glitches. But if top-of-line quality is the priority, then alternatives supported by MOQ caches might be the better option. With MoQ, “we can make available different latency regimes on the same stream,” Law notes.
Glass-to-glass tunable latencies with variable levels of buffering protection can range from real-time at 200-400ms to what Law calls “interactive live” for use in sports betting, online casino gambling, banking and similar applications at 2 seconds, to “conservative live” with persistent HD, 4K or, eventually, 8K quality at 5 seconds.
Moreover, depending on how MOQ-ready CDNs are designed, MOQ can also support recording live content for short-term replay and catchup and long-term storage for VOD archives and cloud DVR applications. “VOD just means my cache is big enough to hold stuff that was live a while ago,” Law says.
Paralleling MOQT development, there are other IETF initiatives underway that are aimed at creating a practical operating environment for the transport protocol, all of which are under the umbrella Law wants to be known as MOQ without referencing it as an acronym for Media over QUIC, much as QUIC itself is now considered a standalone name rather than the acronym it once was for Quick UDP Internet Connections as originally posited by its developers at Google.
One MOQ-related protocol now under development is the streaming format known as WARP, another name shorn of acronym references, which offers a usable example of how content can be encoded, encrypted and packaged in MOQ payloads for commercial video streaming services. As Law notes, the decoupling of transport from media formats and codecs allows CDNs to deploy MOQ Transport as a service and all MOQ-compatible streaming formats, much as HTTP supports HLS, DASH and other formats.
“There’s no limit to the number of streaming formats that can use transport,” he says. “We want CDNs to deploy this at scale and globally as a service where I can bring my applications and plug them in and just use it.”
It’s possible to create application-specific streaming formats that may or may not involve video, he adds, such as might be used for chat services, autonomous vehicle operations, industrial IoT or smart city management. Notably, open-source based development of streaming formats as a spur to the use of MOQ is one of the goals set for the still-forming OpenMOQ Consortium, which as an initiative independent of IETF instigated by Akamai has drawn publicly acknowledged support from Oracle, Cisco, YouTube, Synamedia, and CDN77 along with the interest of many other entities.
“Cisco is very interested in MOQ,” Law says. “They’re building out the next-gen Webex client to use it.” This will enable video chatting depending on users’ choices of codecs at HD 1080p or, if the user has the bandwidth, 4K UHD with full-screen display like one would get currently with an enterprise premium teleconferencing service.
As for other MOQ-related IETF initiatives, Low Overhead Media Container (LOC) specifies a lighter weight approach to stream layer packaging that’s targeted to align with media formats using WebCodecs, a standard defining interfaces with encoders and decoders used in internet communications. There’s also CAT-4-MOQT, which defines how tokens can be used to prevent unauthorized access to MOQ networks and use cases, and CARP, which allows content packaged in the Common Media Application Framework (CMAF) for conventional HTTP streaming to be used in WARP-formatted streams over MOQ.
The very good news coming out of this extraordinary brain dump from the IETF stream squad is that, based on demos, documentation and our conversations at IBC, there’s no reason to doubt the sausage making will lead to a much-needed standard sometime in 2026 that’s capable of unleashing the pent-up RTIS demand at world-changing scale. So now the overarching question is, how soon will CDN operators deem MOQ demand sufficient to merit investing in the multi-CDN infrastructure that will be needed to provide a ubiquitous alternative to HTTP on commodity servers running in datacenters worldwide?
It won’t come cheap, given the fact that MOQ is not compatible with CDNs solely tuned to HTTP streaming. Existing CDN operators will have to dedicate additional server resources to running origin and relay applications of MOQ software, much as anyone has to do when mounting WebRTC-based RTIS infrastructures. In terms of creating the support infrastructure, “WebRTC and MOQ are cost equivalent,” Law says.
But at least the abundance of distributed cloud computing resources provided by Akamai and other hyperscalers worldwide should make it easy for cloud-based CDNs to tap the resources they need to expand into MOQ streaming. Of course, the hunger for AI processing support from AI-optimized GPUs could overwhelm the rapidly expanding datacenter footprint, but the returns on the rest of the CPU and GPU resource base seem sure to keep that side thriving, especially if it means the opportunity to support a transformed approach to how people engage in the networked economy.
Based on what’s been demonstrated so far, the MOQ infrastructure investments may not be long in coming.
As described by Cloudflare systems engineers Mike English and Renan Dincer, Cloudflare has launched the world’s first MOQ relay network running in compliance with MOQT Draft 7 on all its datacenter servers in over 330 cities. “We're joining Meta, Google, Cisco, and others in building implementations that work seamlessly together, creating a shared foundation for the next generation of real-time applications on the Internet,” they said in their August blog. “We want developers to start building with MoQ today.”
Toward that end they’ve made the MOQ infrastructure available for testing use cases at any scale free of charge. While the system is based on an outdated MOQT draft, users are averaging end-to-end latencies at 368ms.
As Law says, “Not bad for a POC.”