This package contains the experimental results obtained in the ERASER project. ERASER stands for Experimenting with Real Application-specific QoS Guarantees in a Large-scale RINA Demonstrator and is a project funded by the 3rd Open Call of the Fed4FIRE+ project (https://www.fed4fire.eu). Experiments have been conducted over a 5G metro/regional RINA network scenario spanning from the end-user terminal until the server where applications run in the datacentre has been defined. Over the last years, the clean-slate Recursive InterNetwork Architecture (RINA) (http://pouzinsociety.org) has attracted significant interest from the Future Internet research community, seen as a viable solution to solve the well-known limitations of the current TCP/IP-based Internet, e.g., in terms of routing scalability, application-specific Quality of Service (QoS) delivery or built-in security. The ERASER project targeted experimental evaluations of the QoS guarantees that RINA can deliver to heterogeneous applications. These experiments have been conducted over the Fed4FIRE+ Virtual Wall experimentation facility hosted and operated by imec in Ghent (Belgium). First experiments in ERASER have contemplated a 10-node small-scale RINA scenario, aiming to integrate all RINA-related open source implementations and tools needed for the entire experiments and validate their operation to meet the ERASER objectives. Two alternative QTA-Mux (i.e., the policy responsible for the RINA QoS support) deployment scenarios have been considered. This has been followed by a definition of the QoS classes (referred to as QoS Cubes in RINA) that QTA-Mux has to enforce, with their relative requirements in terms of losses and delay, as well as the characteristics of the synthetic application flows that will be injected in the network. Second experiments consider a large-scale metro/regional RINA network scenario composed of 37 nodes, eventually, where measurements of delay and packet losses experienced by synthetic traffic flows end-to-end have been obtained for the two considered QTA-Mux deployment scenarios and under different load conditions (links operating at 70, 80 and 90% of their effective capacity). The obtained results highlight the need for configuring QTA-Mux at both Service Provider Network and Metro-Regional network layers in order to provide effective QoS differentiation in terms of both delay and losses, particularly under high network congestion (link loads of 80% and 90%). Conversely, configuring QTA-Mux only at the Service Provider Network layer falls short of delivering adequate QoS differentiation, as best-effort packet treatment at the underlying Metro-Regional network layer deteriorates it, with all synthetic application flow types experiencing similar delay and packet loss outcomes end-to-end.