dataesr/scientific-paragraphs-categorization huggingface dataset:
Correlations between the RNA-seq and Ribo-seq replicates are consistently high (Figure  S2A-B ). Moreover, replicates of the RNA-seq and Ribo-seq profiles of each isolate well cluster using PCA analysis (Figure  S3A-B ). Interestingly, we observed a strong correlation between RNA-seq and Ribo-seq data from each sample (Spearman correlation test between 0. 52 and 0. 80), highlighting the relationship between the level of transcription and translation (Figure  S4 ). To gain an overall view of intraspecific variation, we performed strain-pairwise Spearman correlation tests on the two datasets (Figure  1A ). RNA-seq and Ribo-seq correlation matrices showed similar patterns, indicating once again that transcriptional variations were largely reflected at the translational level. Consistently, we observed a strong positive correlation between the coefficients of the two correlation matrices (Figure  1B ).
Next, we sought to identify genes that did not follow these correlation trends in order to detect genes with variable regulation at both levels (transcription and translation). We therefore performed a differentially expressed gene (DEG) detection using the limma R package  (22, 23). Briefly, we compared the expression level of each gene for each isolate at both levels relative to the other 7 isolates (see Methods). We identified a total of 3,429 DEGs (with 1,627 unique genes) and 816 DEGs (with 610 unique genes) in the RNA-seq and Ribo-seq datasets, respectively (Table  S2 ). The number of DEGs varied greatly depending on the isolates, as it ranged 143 and 1,136 for the RNA-seq (median = 328) and from 17 to 533 for Ribo-seq (median = 34) (Figure  S5A-B ). The CQC isolate shows the highest number of DEGs, consistent with that this strain having the most different transcriptome and translatome profiles (Figure  1A  and Figure  S3 ).
Gene expression is known to differ across individual. We observed that the translational and transcriptional variations were similar in terms of trends and functions, with metabolism-related genes displaying the greatest variation while the translation regulation of essential genes and protein complexrelated genes were more conserved across individuals. These results are consistent with recent largescale exploration of mRNA abundance  (45)  and highlight that gene expression plasticity might be driven by the metabolism preferences between isolates coming from very different environments  (46). Conversly, expression variation of genes with central and essential functions is likely to be deleterious and tend to be therefore more conserved  (47). Our dataset also allowed to get better insight into the phenomenon of post-transcriptional buffering at the translational level  (13) (14) (15) (16).
As suggested by several analyses of our dataset (e. g. , Euclidean distances, isolate pairwise correlation level, |log2(FC)|), we found lower variability in gene expression at the translational level. Taken together, these results clearly indicate the presence of posttranscriptional buffering in our dataset. Overall, we found that, almost half of the genes (44. 8%) on average showing transcriptional variation are affected by this phenomenon, highlighting the central role it plays in shaping translational variation across individuals. Interestingly, we found that post-transcriptional buffering has a specific signature. It preferentially affects genes that are essential or related to protein complexes, as well as genes with low transcript levels. Several reasons could underlie this preferential buffering.
Detection of a post-transcriptional buffering phenomenon In order to see if expression variation across the 8 isolates was stronger in RNA-seq or Ribo-seq data, we firstly computed the Euclidean distances between each strain using the normalized data from both datasets. We also compared the isolates pairwise correlation (displayed in figure  1 ) obtained with the Spearman correlation test. We finally quantified the expression variation (in both RNA-seq and Riboseq data) based on the log2(FC): For each gene in each isolate comparison: |log2( !"#$%&'()* ),-#). '"/ 0)/) 1. 2#%'/ 3 !"#$%&'()* ),-#). '"/ 0)/) 1. 2#%'/ 4 )| The more this value increases, the more variable is gene expression between to isolate for a specific gene. We then sought to explore the extent of the phenomenon by looking at which genes were affected by post-transcriptional buffering.
We used the tAI (tRNA adaptation index) index (41,42) to estimate the codon bias usage of each gene. Briefly, tAI is an index showing how much a gene is adapted to the tRNA genome structure in terms of codon usage. In this perspective, we first calculated the tRNA copy number of our 8 strains with tRNAscan-SE with default parameters (70,71) using the assembled genome sequences from (20). Then, for each isolate, we used the tRNA copy number to compute the tAI using a Perl program available on https://github. com/mariodosreis/tai (41,42) using default parameters. The resulting dataset was a tAI value for around 5,600 genes (some genes were discarded during the calculation) in each isolate. Ultimately, we could calculate an overall tAI (mean of the 8 or less tAI values) for 3,746 genes. For each isolate, we correlated the expression levels to the tAI values.
Acknowledgments We would like to thank  Anne Lopes  for helpful discussions on the manuscript. We are grateful to all the members of the  Iwasaki laboratory  for constructive discussions and technical help. This work was supported by a  European Research Council (ERC)   Consolidator grant  ( 772505 ) to J. S. And E. T. was supported by the  PhD Joint Programme CNRS & Weizmann Institute  and a fellowship from the medical association  la Fondation pour la Recherche Médicale  ( FDT202204014796 ). J. S. is a Fellow of the  University of Strasbourg Institute for Advanced Study (USIAS)  and a member of the  Institut Universitaire de France. S. I. was supported by the  Ministry of Education, Culture, Sports, Science and Technology (MEXT)  (a  Grant-in-Aid for Transformative Research Areas [B]  " Parametric Translation ",  JP20H05784 ), the  Japan Society for the Promotion of Science (JSPS)  (a  Grant-in-Aid for Young Scientists  [A],  JP17H04998 ; a  Challenging  Research [Exploratory],  JP19K22406 ),  AMED  ( AMED-CREST ,  JP20gm1410001 ),  RIKEN  ( Pioneering Project  " Biology of Intracellular Environments" and Ageing Project ), and the  Takeda Science Foundation.
Acknowledgements We are indebted to the  Animal Facility  at the  CBI-FR3743/Université Paul Sabatier Toulouse III  for providing the strains used in this study. We thank  F. Capilla  for the use of the histology facilities at the  Centre Regional d'Exploration Fonctionnelle et de Ressources Expérimentales, Toulouse Purpan ,  A. Le Ru  and  C. Pouzet  from the  Toulouse Reseau Imagerie and FR Agrobiosciences Interactions Biodiversity  for automated light microscopy imaging ( Nanozoomer Hamamatsu ) and  C. Rouvière  for help with bone morphometry analysis using Image J software. The French FERMaT Federation FR3089 is acknowledged for providing X-ray tomography laboratory facilities.
SD-WAN [1]. The Google B4 WAN  [2]  [3] is a proprietary SD-WAN solution that connects Google's data centers across the world. B4 relies on a hybrid Software Defined Networking (SDN) approach: the WAN sites are interconnected using traditional routing protocols, an SDN-based Traffic Engineering service runs on top of the network to maximize links utilization and perform load balancing, OpenFlow is used to control and program the switches. FlexiWAN [4]  was the first open source solution. It uses Virtual Extensible LAN (VXLAN)  [5]  tunnels to establish the SD-WAN interconnections. In our previous work  [6] , we presented an open-source SD-WAN solution called EveryWAN, which is capable of using Segment Routing over IPv6 (SRv6) to establish the SD-WAN interconnections. To the best of our knowledge, EveryWAN is the first opensource solution to leverage SRv6 technology to create SD-WAN services.
EveryWAN is based on Linux networking and can be deployed on software routers located at the edge of an SD-WAN. In fact, software routers can play a role in SD-WAN scenarios, thanks to their flexibility, complementing hardwarebased solutions. For example, they can be easily deployed in virtualized environments in cloud and data center scenarios as VNFs (Virtual Network Functions) as shown in Fig. 1. For this reason, we believe that it is fundamental to work on the design and implementation of open-source SD-WAN solutions suitable for software routers. An important function to be executed in wide area networks is Performance Monitoring (PM). PM allows network operators to detect failures and outages and assess network performance. Effective network monitoring is essential, and new tools and protocols have been designed accordingly for SDN-based networks  [7].
IV. THE EVERYWAN ARCHITECTURE EveryWAN  [6]  is an open-source SD-WAN prototype based on Linux networking. Fig. 5  shows the EveryWAN architecture. At the lowest level, we have the SD-WAN Edge routers called EveryEdge routers. The EveryEdge routers take care of the interconnections among all the sites. EveryEdge routers can be deployed as Virtual Network Functions (VNFs) over a Linux OS in the sites to be interconnected. An SD-WAN Controller, called EveryEdgeOS, manages all the EveryEdge routers through an API based on the gRPC Remote Procedure Call (gRPC) protocol. gRPC  [10]  is a high-performance RPC (Remote Procedure Call) framework that was initially developed by Google and is now maintained and supported by an active community of developers. EveryEdgeOS deals with many configuration and management aspects of the EveryEdge routers, ranging from their initial registration, authentication, and configuration to the activation of the policies that implement the SD-WAN services.
On top of the controller, there is an SD-WAN Orchestrator named EveryBOSS, which automates the deployment of the EveryEdge routers and SD-WAN services. The orchestrator also offers a GUI that allows the customers to configure the EveryEdge routers and manage the SD-WAN services. The EveryEdgeOS and the EveryBOSS orchestrator can run either in a self-managed private cloud or in a public cloud. The EveryEdge router comprises several open-source components installed on a general-purpose Linux distribution (e. g. , Ubuntu Server). It uses Linux networking capabilities to forward the traffic. A component called EveryEdgeManager offers a Southbound API that is used by the EveryEdgeOS controller to program and configure the router. Through the Southboud API, the controller can send commands to the EveryEdge router (e.
g. , install a specific route or set the IP address of a network interface). The EveryEdgeManager translates the received commands into lower-level actions. Then, it sends these actions to the Linux kernel using the opensource pyroute2  [26]  library. Pyroute2 is a Python package that provides a programming interface for network configuration and management on Linux systems. Pyroute uses the Netlink protocol, which is a mechanism for communication between the kernel and user-space processes. A detailed description of the EveryEdge router architecture can be found in  [6]. The main service offered by EveryWAN is Network Slicing (described in Section III), which allows customers to create End-to-End Slices among the remote sites. The EveryEdge router receives ingress IP packets over the customer-facing interfaces, i.
A. Data Plane Protocol A STAMP session measures the end-to-end delay on a given SRv6 path between two nodes, the STAMP Session-Sender and Session-Reflector. A STAMP session consists of a bidirectional packet exchange between the STAMP Session-Sender and the Session-Reflector. Each STAMP session is identified by a unique 16-bit nonzero unsigned integer called STAMP Session IDentifier (SSID). The STAMP Session-Sender transmits a STAMP Session-Sender test packet to the STAMP Session-Reflector. The test packet is an IPv6/UDP packet sent to the STAMP UDP port of the Session-Reflector. By default, the STAMP Session-Reflector uses the UDP port 862. The SDN controller can set a different port during the configuration of the STAMP Session-Reflector. The STAMP Session-Sender test packet is transmitted on the same path as the data traffic flow under measurement to measure the delay experienced by the data traffic flow.
C. Data Collection The STAMP Session-Sender and STAMP Session-Reflector exchange STAMP Test packets containing the timestamps required to compute the delay. The STAMP Session-Sender collects all the timestamps. The SDN controller can interact with the Session-Sender to fetch the timestamps. In general, there are two approaches the SDN controller can use to fetch the timestamps: polling mode and notification mode. In polling mode, the controller periodically polls the Session-Sender to gather the collected timestamps. In notification mode, the Session-Sender will "push" the information toward the SDN controller, either by sending the single measurement records or aggregating a set of measurement records in a single notification. In our solution we have implemented the polling mode. When the measurements records are available to the SDN controller, it can compute the delay of the direct path d d (i.
VI. STAMP FOR SRV6: ROUTER IMPLEMENTATIONS We have realized an open source prototype of the proposed STAMP for SRv6 solution, see  [36]. In this section we describe the implementation of the router functionality (Session-Sender and Session-Reflector), in section VII we focus on the SDN Controller and Orchestrator. The main Data Plane tasks of the Session-Sender (described in Section V) are the following: i) generate and send STAMP Session-Sender Test packets to the STAMP Session-Reflector; ii) receive STAMP Session-Reflector Test packets from the Session-Reflector and collect the timestamps. Concerning the STAMP Session-Reflector, its main Data Plane tasks are: i) receive STAMP Session-Sender Test packets from the Session-Sender; ii) send a STAMP Session-Reflector Test packet to the Session-Sender for each received STAMP Test packet.
B. User Space Implementations for Data Plane In this subsection, we describe our user-space implementations of the STAMP Session-Sender and Session-Reflector, compliant with RFC 8762  [28] , RFC 8972  [29] , and draft  [31]. The implementations are based on Scapy  [39] , a packet manipulation library written in Python, Scapy provides a programming abstraction to generate and send network packets as well as to receive and decode them. Several protocols are already supported by Scapy and it can be extended to support new protocols. We have developed a first STAMP implementation (referred to as basic) and then designed an improved version (referred to as optimized). Hereafter, we first describe the basic Scapy user space implementation and then we discuss how we have tackled its performance issues with the optimized implementation.
The L3RawSocket6 is a Scapy socket built on top of a AF_INET6/SOCK_RAW Linux socket. The Linux kernel adds a Layer 2 header and sends the packet to the destination (i. e. , the Session-Reflector or the Session-Sender) according to the usual L2/L3 rules. Both the Session-Sender and the Session-Reflector need to process the incoming STAMP Test packets. The Session-Reflector receives the STAMP Session-Sender Test packets from the Session-Sender and it has to reply to these packet by adding the proper timestamps. The STAMP Session-Sender receives STAMP Session-Reflector Test packets from the Session-Reflector and processes them, acting as a measurement data collector. The Session-Sender and the Session-Reflector run a dedicated thread to capture, validate and process the STAMP Session Test packets.
As explained previously, the basic implementation relies on the Scapy AsyncSniffer to capture the STAMP Test packets. AsyncSniffer is implemented using a Linux AF_PACKET/SOCK_RAW socket. An AF_PACKET/SOCK_RAW socket captures all the packets received on a given interface. The capture process of a plain AF_PACKET socket is very inefficient, because it uses very limited buffers and requires a system call to capture each packet. The second bottleneck of the basic implementation is related to the process of building and dissecting the STAMP Test packets. The Session-Sender periodically generates and sends STAMP Test packets to the Session-Reflector. Generating a STAMP Test packet involves several operations, such as building each layer, filling each header with the proper information, stick all the layers together, and computing the checksum.
Then it computes the UDP checksum and sends the packet to the Session-Reflector. In this way, we avoid the overhead related to generating a new STAMP Test packet from scratch. To further improve performance, we save the STAMP Test packet as a bytes array instead of a Python object. In this way, we avoid the overhead due to converting the packet from Python representation to a bytes array before sending it on the network. We also optimized the logic used to parse the received packets. For each received STAMP Session-Reflector Test packet, Scapy performs the so-called packet dissection, i. e. , it reads the bytes of the packet and builds a Python object to represent the packet. Then, it collects the timestamps from the packet. In the optimized solution we bypassed the Scapy dissector and we extract the timestamps directly from the bytes representation of the packets.
C. eBPF Implementation for Data Plane eBPF  [11]  is a Linux technology that can be used to accelerate network packet processing. With eBPF it is possible to deploy programs in kernel space and in a sandboxed environment, without having to write ad-hoc kernel modules or change the kernel code. eBPF can offer high performance to specific packet processing tasks. We designed and implemented a proof-of-concept eBPF implementation with the goal to assess its performance. Our eBPF deployment is based on the HIKe / eCLAT  [41] [42]  framework. HIKe (Heal, Improve and desKill eBPF) is a virtual machine abstraction for eBPF. It makes it possible to chain multiple eBPF programs in a larger and more complex program. eCLAT (eBPF Chains Language And Toolset) is a python-like language and programming framework.
Its scripts compile to HIKe chains, providing a high-level, simpler language that can be used to compose complex eBPF programs in a modular fashion. Algorithm 1 HIKe chain high level structure for STAMP Session-Reflector. if packet is STAMP then process headers for layers 2, 3, 4 compute UDP checksum cross connect to layer 2 interface else pass packet to kernel end if The high-level pseudocode 1 shows the structure of the HIKe chain for the STAMP Session-Reflector. The chain is attached to the eXpress Data Path (XDP) hook on the desired interface and the entire processing is performed without letting the packet enter the Linux kernel networking stack. The first eBPF program filters only STAMP Test packets, everything else is passed to the kernel without further processing. The chain then manipulates the STAMP fields adding the new timestamps.
Then, the address/port fields in MAC, IPv6 and UDP headers are changed before forwarding the packet. Lastly, the UDP checksum is recalculated and the packet is forwarded on the desired interface. The Collector implementation is simpler because the packet does not need to be forwarded. The chain comprises a filter so that only STAMP packets are processed, while other packets are sent to the kernel networking stack. Then we have the actual Collector eBPF program. It parses the STAMP payload of the packet and extracts the timestamps. The extracted timestamp records are written inside an eBPF map, accessible from the userspace, so that it is possible to read the measurements. The code for the eBPF implementation can be found in the repository  [43]. The deployment and configuration of the eBPF implementation is not integrated in the EveryWAN prototype.
The logical topology is shown in Fig. 11. On the TG node, we installed TRex  [48] , an open source traffic generator powered by DPDK  [49]. The SUT node runs an Ubuntu 20. 04 LTS Linux distribution with Linux kernel release 5. 13 and hosts our STAMP implementations. To control Linux networking capabilities (e. g. , network interfaces, routing, and SRv6 behaviors), we installed the 5. 13 release of the iproute2 [50] suite. We also installed ethtool 5. 13 to configure the hardware capabilities of the NIC, such as offloading  [51]. To perform the experiments, we used SRPerf  [52] , a performance evaluation framework for software and hardware implementations of SRv6. SRPerf orchestrates and automates the execution of the experiments using the TRex Python automation libraries  [53]. It interacts with the TRex generator installed on the TG node.
When the percentage of STAMP traffic is very low, it does not affect the overall performance and the filtering is the only factor that plays a role. When the STAMP traffic increases, the throughput of the eBPF implementation increases because the STAMP packets are not sent to the kernel networking stack and they are processed faster by our eBPF program than the SRv6 packets that the kernel is encapsulating. On the other hand, the Scapy implementations process the STAMP packets in the user space, hence the performance is reduced when the fraction of STAMP packets increases. The Session-Reflector throughput for different value of the percentage of STAMP measurement packets is shown in Fig. 16. The results for the three implementations are consistent with what we have discussed for the Session-Sender/Collector implementation.
In this respect, we have given a positive answer to the first two research and technological questions outlined in the introduction: i) the proposed approach based on IETF standards and current Internet drafts is an effective solution for delay monitoring of SRv6 networks; ii) we were able to implement the Delay Monitoring in an open source prototype based on Linux software routers, covering both the data plane aspects and the control plane aspects. Then, we have addressed the research questions related to the performance impact of delay monitoring procedures on a Linux software router. We have implemented the proposed solution in three different versions and executed a number of performance experiments to evaluate and compare the three implementations. We have started with a naive user space implementation of STAMP based delay monitoring, but we realized that its performance was poor, with a high reduction of the forwarding capacity of the software router.
We have optimized the user space implementation, achieving an acceptable performance impact. In particular, with the optimized user space implementation the impact is acceptable when the fraction of measurement packets is kept within reasonable limits (e. g. less than 0. 1%). We think that these limits will not be exceeded under practical operational conditions, as the number of measurement packets will always be a small fraction of the data traffic. Therefore, we have integrated the optimized user space implementation in our open source SD-WAN framework, which now offers a running prototype of the delay monitoring solution. We further considered a third implementation, based on the Linux eBPF technology. This proof-of-concept implementation providee a positive answer to question about the feasibility of delay monitoring in SD-WANs with negligible impact on the forwarding capability of a Linux software router.