Video traffic treatment 2.0: What’s the secret recipe of SCONE?

No, we are not talking about a tasty pastry. SCONE is a new standardization effort to improve video traffic treatment and actually there isn’t really any secret ingredient here. It’s a simple, rather small protocol that can benefit both the users and the network.  

SCONE (Standard Communication with Network Elements) is a newly formed working group in the Internet Engineering Task Force (IETF). The working group is scoped to standardize a protocol – also named SCONE – that enables a new way of in-band communication to provide throughput advice from the network to the communication endpoints, alongside the actual data flow. The primary motivation for this work comes from video traffic management: connectivity providers can expose rate limits (instead of throttling traffic themselves), so the communication endpoints can adapt accordingly, for example by restricting available Adaptive Bitrate (ABR) video tracks. How this works in detail is further explained below.  

This approach provides the following advantages: 

• Reduced network resources: compared to in-network video shaping solutions, SCONE does not require computational and buffer resources to detect and manage video flows. With SCONE, these resources can be reduced or even entirely removed. 

• Better quality of experience: Endpoints can optimize their own performance based on network-provided information, rather than trying to adapt to the (shaped) transmission rate imposed by network policing (such as Maximum Bit Rate (MBR) dropping) or shaping. 

In summary, in-band communication of throughput advice information enables applications to self-adjust. This approach ensures better quality of experience for end-users, while still preserving the volume reduction properties of video throttling or shaping that contribute to radio network efficiency.  

But let’s start from the beginning.  

What’s the problem today?  

Certain network functions located along the data path – such as the User Plane Function (UPF) – currently apply rate limits on traffic flows, most often targeting video streams, to reduce network resource usage. For instance, the UPF can enforce an MBR based on subscriber-specific policies. 

This mechanism is effective because many applications, particularly video applications, can adjust their bit rate based on network conditions. These applications implicitly attempt to figure out what the usable bitrate is. It is done dynamically on a short time scale (minimum one round trip-time) using congestion control. In addition, video traffic also normally uses Adaptive Bitrate (ABR) streaming that aims to keep the effective video bitrate below the congestion level. ABR streaming is shown schematically in the figure below.  

Fig-1 A schematic illustration of ABR video. It shows a smartphone with a video client on the left and a video server on the far right. Between these is a speedometer icon representing network speed and a play button on top of colored blocks that represent video encoding levels. Arrows from the video client to the video server represent video streams.

The video server holds multiple encodings of the same video with different quality levels. The video client first requests the highest encoding (green). Later, for example because the network is slower than expected, the client changes and requests a lower coding level instead (blue).  

The adaptability of video traffic is used by network operators as a means of controlling traffic volume. One way is to implement ABR shaping, which is a technique where video traffic is shaped to a bitrate that corresponds to a potential ABR quality track. The ABR clients will measure the available network capacity and adapt their media bitrate to the shaping rate.  

As shown in the figure below, in-network shaping utilizes the adaptivity of ABR video traffic to shape traffic to a lower throughput rate. However, this also limits the usually rather dynamic video traffic to a maximum rate, which can negatively impact user experience. While shaping smooths the traffic by buffering, policing – which immediately drops the traffic when the limit is exceeded – can have an even more negative impact on user experience. 

Fig-2  The image shows two side-by-side graphs illustrating bitrate shaping. On the left, a jagged purple line fluctuates above and below a dashed horizontal line indicating Bitrate. On the right, after shaping (indicated by a blue arrow), the line becomes smooth and stabilizes near the dashed line, showing controlled bitrate for consistent video quality.

While ABR shaping or policing are useful tools to manage network load and provide subscription differentiation, they have a number of potential downsides from an end-user quality of experience perspective.  

• Traffic shaping and policing only provide an implicit signal to the application. Therefore, the application needs to discover the available rate by trial and error, which means that it takes some time to converge on the optimal media bitrate.  

• The transmission of initial video segments is slowed down. As a consequence, it takes longer from request to initiation of the video playback.  

How does in-band throughput advice signaling in SCONE work?

The SCONE charter states that the working group shall:  

The exact nature of the “throughput advice” is currently under discussion by the working group, but at the very least, the signal should consist of a bitrate and be interpreted as:  

Usually, this bitrate lies below the maximum capacity of a certain “link” or network segment. It represents a kind of “fair share” for a certain user subscription and application, such as video. The application also benefits from this kind of advice, as it can provide video content at a more stable rate than if it always aimed for the maximum possible capacity. 

Signaled bitrates are not supposed to be dynamically adapted based on immediate network load, but network state awareness, for example average cell load, can be factored into the communicated bitrates.  

Note that the reported throughput bitrate advice may be higher than what is actually achievable at any given moment, for example due to bad channel conditions or other kinds of congestion. In such cases, the data transport congestion control will become active with the aim of keeping the sending rate at a lower level, as further detailed below.  

The working group is looking into two possible realizations; one based on MASQUE and another one that defines a new QUIC version. As both provide similar functionality, this post will only go into details of the QUIC-based version.

QUIC-based wire format  

At the time of writing this blog post, the SCONE protocol is being specified by the SCONE working group. The specification in its current version defines a SCONE packet as a packet that conforms to the version independent properties of QUIC as defined by RFC 8999.  

SCONE Packet {
  Header Form (1) = 1,
  Reserved (1),
  Rate Signal High Bits (6),
  Version (32) = 0x6f7dc0fd or 0xef7dc0fd,
  Destination Connection ID Length (8), Destination Connection ID (0..2040),
}

The SCONE protocol has a number of properties: 

1. Signals are sent in SCONE packets that are QUIC long-header packets that use distinct versions. Combining the six low bits of the first byte with the highest bit of the version field creates a 7-bit rate signal field. 
2. The rate signal field encodes a logarithmically spaced distribution of bit rates ranging from 100 Kb/s to 199.5 Gb/s.
3. Endpoints agree on the use of SCONE by use of QUIC transport parameters.
4. SCONE packets are generated by the endpoints and are inserted in front of regular QUIC packets in a UDP datagram.
5. Network elements can detect SCONE support for a UDP4-tuple by observing SCONE packets. The protocol also supports an “early SCONE indication” that is sent with the first packets of a flow.
6. Network elements communicate throughput advice by modifying the rate signal field in the SCONE packets it observes. This is possible since SCONE packets are neither authenticated nor encrypted. 

Bullet 4 is an important aspect for the ability to deploy and roll out a solution. No additional out-of-band discovery procedure is required to initiate the signaling, which is a favorable difference to Masque and other out-of-band exposure solutions.  

How do mobile networks benefit from in-band throughput advice signaling?

The SCONE mechanism for throughput advice signaling offers an alternative to in-network shaping or policing. Maximum radio network efficiency can be achieved, while also providing the best end user quality of experience.  

Endpoint-based self-regulation at the application layer selects a media bitrate that fits within the throughput advice signaled by the network. Using this signal for application layer adaptation enables full utilization of the available network capacity when media segments are transmitted, while limiting the total volume used by a media application. Sending the information in-band – instead of using a separate out-of-band interface – makes it easy to associate the signal with a specific flow and consume it in the endpoints.  

This approach can enable greater radio efficiency, leading to higher user perceived throughput. For the end user, it means that media segments are downloaded more quickly, so playback can start sooner and the risk for video stalls is reduced.  

A network element that wishes to communicate a bit rate should consider all available factors that influence rate-limitation. Examples include maximum bitrate for the entire data session, the QoS flow, and the video application. Even for networks where throttling is not implemented today, a throughput bitrate advice could be signaled. For instance, a network operator might signal a desired upper bound for video throughput, without actually enforcing it.  

Timescales for throughput advice signaling and SCONE’s relation to congestion control and L4S  

SCONE throughput advice can operate on different timescales, as illustrated in the figure below.  

Fig-3 A flow diagram showing three inputs on the left leading to a central box labeled “Rate limit decision,” which then points to a gauge on the right labeled “Rate limit.” The inputs are: “Tracking of and reaction to changes to network state” “Policy changes during active user session” “Static policies Subscription” The gauge has a needle pointing toward a moderate position, indicating the applied rate limit.

At the bottom, completely static policies, tied to a subscription as an example. One level up, a policy that can change during an active session. At the top a dynamic policy where SCONE can track and react to changes in network state.  

Notably, SCONE throughput advice is designed to operate over much longer timescales compared to what's needed for congestion control. Congestion control mechanisms, including scalable congestion control as used in L4S, function on round-trip-time scales, while SCONE throughput advice signals remain valid for tens of seconds or more. 

The figure below roughly describes the two mechanisms, application layer adaptation with SCONE and L4S-based congestion control, as well as the difference between them.  

Fig-4 A layered diagram illustrating data flow between a client and server in a streaming context. At the top, the Application layer shows an App receiver on the client side with a playback buffer and playback module, and an App sender on the server side with a data source and rate control (app queue). Arrows indicate “Over the top” rate adaptation between sender and receiver. Below that, both sides have Transport layers exchanging data and congestion feedback, with scalable congestion control (CC) on the sender side. At the bottom, the Network layer (IP) and Link/Physical layers convey L4S capability and indicate congestion, with labels for ECT(1), CE, and congestion detection.

While SCONE provides an upper bound on achievable throughput, it does not provide any guarantees that the throughput is available. Therefore, it needs to operate jointly with congestion control mechanisms that limit sending rates when capacity is lower than the limit advertised by SCONE. However, congestion control operates at a lower layer and smaller time scale.  

As shown in the figure above, congestion control sits in the transport layer (green). It reacts based on congestion signals provided through the network layer (blue), for example by the Congestion Experienced (CE) code point used by ECN and L4S, that indicate buffer exhaustion in the network buffer in the lower layers (orange). The throughput limit provided by SCONE is, however, applied in the application layer (purple) to limit the video bitrate to a level below the maximum link capacity where congestion would occur.  

Upon receiving throughput advice, a client endpoint can request a media track from the server that fits the advice. If the transport layer congestion control limits the sending rate below the advised throughput, the application will adapt to that limit instead. This is schematically shown in the figure below.  

A line graph comparing network behavior in two regions: Uncongested network (blue background) and Congested network (pink background). The x-axis represents time, and the y-axis represents sending rate. Three curves are shown: Maximum available capacity (dashed line) stays high except for a sharp drop during congestion. Actual video sending rate (solid line) follows capacity but dips significantly in the congested region. SCONE throughput advice (wavy line) oscillates below capacity, adjusting dynamically. Labels indicate “SCONE-limited” in the uncongested area and “CC-limited” in the congested area.

The pink area indicates a short time of high network load and the video sending rate has to drop below the throughput advice to conform to the congestion control limit.  

Combining SCONE with L4S, which utilizes a more scalable congestion control to keep latency particularly low, provides stable bounded throughput combined with low latency in case of high network load. For more information on L4S please refer to the joint Ericsson and Deutsche Telekom L4S white paper.  

Integration of the SCONE throughput advice signaling protocol in the 5G Core network 

When using SCONE, the role of the 5G Core (5GC) is to share the applicable rate limit using SCONE and an operator can then decide to either:  

1. completely omit enforcement of rate limitation, regardless of the flow throughput, 
2. omit enforcement of rate limitation if the measured flow throughput is within a tolerated range or  
3. maintain enforcement of rate limitation.  

For all cases above, the 5GC, particularly the UPF, needs to be able to detect SCONE traffic in order to convey new rate limits to existing flows and sessions. For cases 1 and 2 above, the 5GC further needs to be able to monitor conformance to the rate limit, as well as log and potentially report policy breaches. Cases 2 and 3 can be used with existing rate limiting policies, based on CSP preferences. In addition, the 5GC shall be able to configure whether users are charged for traffic that is subject to rate limitations. 

Considering these requirements, the SCONE solution can be integrated in the 5GC as follows: The control of the functionality resides in the Policy and Charging Control (PCC) framework. The PCC could control the activation of SCONE, activation or deactivation of rate limitations in the 5GC user plane (UP), signaling of rate limitation information from the CP to the UP, activation of QoS monitoring, configuration of charging, and more.  

Most of the SCONE functionality resides in the 5GC UPF, as it is an in-band solution. It is the UPF internal logic that coordinates the activation and deactivation of the different functions. The UPF functionality can be broken down into three blocks: 

• Throughput advice sharing (by means of SCONE), for the actual sharing, upon request, the throughput advice in-band. 
• Data-rate monitoring, which measures the application data rates and can be used to determine whether endpoints are enforcing the throughput advised. 
• Policing and shaping, which is the in-network enforcement of the data rate limit.  

The blocks require inter-UPF coordination among them and UPF-based communication with the CP, as illustrated in the figure below.  

Fig-6 A diagram showing SCONE functionality in the 5GC. At the top is a box labeled CP (Control Plane) connected by a double arrow to a larger dashed box representing Intra-UPF coordination. Inside this box are three elements: Throughput advice sharing by SCONE on the left Policing/Shaping on the right Data-rate monitoring in the center, illustrated with two blue circular arrows forming a loop. In the intra-UPF box is a circular loop made of two thick arrows pointing clockwise, forming a cycle moving continuously between the three elements.

A potential additional service is to expose the 5GC SCONE functionality through the 3GPP exposure framework so that endpoint(s) can explicitly request the SCONE capabilities from the mobile network.  

In theory, it would be possible to design an API-based, out-of-band mechanism directly within the 5GC architecture, as an alternative way to provide the throughput advice through the exposure framework. However, several factors need to be considered to determine the most appropriate solution:  

• Signal dynamicity and frequency: mostly static/subscription based vs. based on traffic/load dependent 
• Flow identification: in band request vs. user or app ID approach  
• Architectural overhead and complexity: local decision and signal at the UPF vs. policy framework and external HTTP API  

With this in mind, out-of-band signaling could provide an easy solution for signaling of relatively static information, like per subscriber limits, which can then be applied to multiple traffic flows. An in-band-signal, however, is less complex when information is adjusted more dynamically for each traffic flow separately, for example based on cell load. Further, as noted earlier, out-of-band signaling can complement the in-band signal by exposing the SCONE capability and provide a way to request it explicitly.  

Conclusion and next steps  

SCONE, currently in standardization, offers a straightforward solution to improve both user experience and network efficiency. It works by signaling throughput advice from the network to the endpoints. The strong interest in this protocol, along with the multiple groups actively working on it, is promising for the prospects of success and timely deployment.  

While SCONE involves only a small change in protocol design and network operations, it can greatly benefit video traffic – today’s most dominant and rapidly growing type of data across both existing and new services. This simple mechanism is a good example of a network-application collaboration approach, where the incentives are aligned for all actors, and most importantly, for the benefit of the users!  

Read more 

Ericsson Mobility Report: Short-form dominates video traffic