## 3 Experiment Workflow
### Traffic Acquisition and Its Characteristics  
For our experiment, we employed six traffic datasets representing four kinds of applications or services which are considered bandwidth-demanding. The dataset represents multiple file downloads, gaming traffic, social media browsing, and DASH video. We list these traces in Table 1.  
We acquired the non-video data traces using Wireshark, which stores the data in binary files. After capturing the data, we filtered out irrelevant packets and converted the binary files into a data frame consisting of data throughput at given time intervals. We captured traffic traces from a session of multiple file downloads, gaming, and a social network. These sessions represent common non-video traffic, which consumes a significant amount of network bandwidth. The file download session was reproduced while upgrading a Linux operating system. During this process, high volumes of network traffic were generated as the system downloaded package updates, dependencies, and any additional files required for the upgrade process. Such sessions are quite common, as OS or application updates are released frequently. Updating is not just about downloading files individually but is a more complex process. Firstly, the package manager downloads metadata from the configured repositories. This metadata includes information about available packages, their versions, and dependencies. Then, it downloads the actual package files that need to be updated or installed. If the upgraded packages have dependencies that are not installed or need to be updated, the OS downloads additional packages. The upgrade process may involve  
Figure 2: The experiment’s stages. We pre-processed the acquired network traffic. Then, we extracted, filtered, and sorted the traffic features. Finally, we clustered the features by traffic type. multiple requests to different repositories, especially if the system is configured to use third-party package sources or mirrors. Due to the proprietary and confidential nature of the gaming industry, access to gaming traffic traces is limited, even in anonymized formats. Game companies are reluctant to share traces or logs, not only because of concerns regarding player privacy but also due to fears that the data could be exploited to undermine the security of their services. For these reasons, the amount of available gaming traces on the Internet is limited. Hence, we collected our dataset generated during Microsoft Flight Simulator. The game consumed a significant amount of network bandwidth, primarily due to its reliance on streaming data for various features. The game streams real-world data, including satellite imagery, terrain, and weather conditions. The streaming demand increases, especially when flying in areas with detailed scenery, with enabled features enhancing the detail of cities and landscapes. Similarly to gaming, due to privacy concerns, social media traffic is not widely available. Therefore, we gathered the traffic during a Facebook session, which included Facebook browsing, reading content, watching multimedia content, chatting, and making video connections. Facebook traffic consists of various types of data. The most common are HTTP and HTTP secure (HTTPs) requests to load pages, images, and videos. Moreover, WebSocket connections used for real-time features like video chat also consume significant bandwidth. Facebook's traffic is a mix of periods of high and low data transfer. These patterns correspond to periods when users are actively engaged with the application or downloading content, and when they are viewing or reading previously downloaded content. We analysed video traffic across three major platforms, namely YouTube, Netflix, and Amazon Prime, which contribute significantly to overall Internet usage [4]. We acquired the traffic traces from [22], which shared more than 46K data traces, among others, from the above-mentioned three services.