RFC 6437 introduces the 20-bit flow label field in the IPv6 header and recommends it to be used alongside source and destination IP addresses for efficient flow classification. A recent paper from Google authors explains how they have begun to use this field in their IPv6 network to select an alternative path, thereby preventing congestion or outages. However, there is no prior research investigating whether connections make use of this field on the Internet. In this paper, we present a comprehensive analysis of the 9-year MAWI dataset (2016-2024), the Internet traces gathered from a large backbone link in Japan, and examine whether the IPv6 flow label is indeed employed on the Internet. Our findings reveal an increasing upward trend in the adoption of the flow label field. In particular, this trend correlates with the use of QUIC, whose specification—different from TCP—explicitly repeats the recommendation to utilize the flow label.

Third molar segmentation on panoramic dental radiographs is crucial for oral diagnosis and effective treatment planning. However, it remains a challenging task due to anatomical complexity, variability, and frequent image artifacts. This work presents a comprehensive benchmarking of state-ofthe-art semantic segmentation models from three architecture families: Convolutional Neural Networks (CNNs), Transformer-based models, and Hybrid architectures. We introduce a novel dataset of 871 annotated panoramic radiographs, labeled with four third molar classes based on the FDI numbering system. The study evaluates U-Net (with MobileNetV2, ResNet34, ResNet50), DeepLabV3, SegFormer, SETR, DETR, and Mask2Former models. All models were trained and compared under a consistent experimental setup with extensive hyperparameter tuning. Performance was assessed using multiple metrics: Mean IoU, Dice Score, Precision, Recall, and Pixel Accuracy. U-Net with ResNet34 achieved the highest segmentation performance (Mean IoU: 0.7771, Dice: 0.8691), closely followed by SegFormer. These results highlight the superior spatial localization of CNNs and the contextual modeling strength of Transformers. In contrast, hybrid models such as DETR and Mask2Former ranked lower, indicating limitations in capturing smaller and irregular anatomical structures in dental radiographs. The outcome of this study offer important insight into the challenges of applying various deep learning paradigms to dental image analysis and underscore the significance of architectural choices and dataset properties in achieving clinically relevant outcomes.

Network researchers, academics, and students often need to deal with complex scripting in order to design a network topology, configure network nodes, automate experimentation, and visualize network performance metrics. Current simulation or emulation tools lack the ability to provide a comprehensive understanding of the network. This paper introduces TeachNet, a lightweight and user-friendly network tool that provides a graphical user interface for designing, configuring, and automating network experiments. We explain TeachNet’s design and present results to demonstrate its effectiveness and efficiency using our TCP experimentation-focused prototype, and Mininet in the backend. TeachNet creates a repository of log files and offers a framework for future research that is easily extensible to accommodate other tools such as OMNeT++ and ns3.

RFC 6437 specifies the usage of an IPv6 3-tuple (flow label, source and destination address fields) for flow classification in routers. Is this the only flow classification approach in use with IPv6 when the flow label is not zero? If so, end hosts could benefit from knowing that multiple flows between the same host pair traverse the same network bottleneck (for example, single-path congestion control coupling mechanisms could then reduce loss and delay). This paper attempts to answer this question with an investigation of whether path consistency is achievable via the IPv6 3-tuple in the Internet. We employ a novel method that extends Paris traceroute to control the path behavior solely using IPv6 network-layer header data, and conduct a large-scale measurement study from globally stationed vantage points to examine i) the extent to which the flow label is delivered to its destination, and ii) how it influences the behavior of load-balancing algorithms. Our results suggest that the flow label always passes through the network unaltered, but the 3-tuple is not a reliable flow identifier in the current Internet.

Most Internet hosts today support multiple access technologies and network interfaces. Multipath transport protocols, like MPTCP, are being deployed (e.g., in smartphones), allowing transparent simultaneous use of multiple links. Besides providing increased resilience to link failures, multipath transports may better exploit available (aggregate) capacity across all interfaces. The safest way to ensure fairness is to assume that any subflows of a multipath end-to-end connection may share bottleneck links, but knowledge of non-shared bottlenecks could allow multipath senders to exploit more capacity without being unfair to other flows. The problem of reliably detecting the existence of (non)-shared bottlenecks is not trivial and is compounded by the fact that bottlenecks may change due to traffic dynamics. In this paper we focus on practical methods to reliably group flows that share, possibly dynamic, bottlenecks online and in a passive manner (i.e., without injecting measurement traffic). We introduce a novel dynamic clustering algorithm that we apply to update our previous shared bottleneck flow grouping (SBFG) method standardized by the IETF, based on delay statistics. We also adapt an offline SBFG method based on wavelet filters to enable it for online operation. These SBFG methods are evaluated by a simple testbed, rigorous simulation and real-world Internet experiments in a testbed comprised of multihomed hosts. Our results suggest that there is no clear winner, and selection of the “best” SBFG method will have to consider tradeoffs regarding accuracy, lag, and application requirements.

DiffServ was designed to implement service provider quality of service (QoS) policies, where routers change and react upon the DiffServ Code Point (DSCP) in the IP header. However, nowadays, applications are beginning to directly set the DSCP themselves, in the hope that this will yield a more appropriate service for their respective video, audio and data streams. WebRTC is a prime example of such an application. We present measurements, for both IPv4 and IPv6, of what happens to DSCP values along Internet paths after an end system has set them without any prior agreement between a customer and a service provider. We find that the DSCP is often changed or zeroed along the path, but detrimental effects from using the DSCP are extremely rare; moreover, DSCP values sometimes remain intact (potentially having an effect on traffic) for several AS hops. This positive result motivates an analysis of the potential latency impact from such DSCP usage, for which we present the first measurement results. We find that routers at approximately 3% of more than 100,000 links differentiate between the WebRTC DSCP values (EF, AF42 and CS1) and consistently reduce delay in comparison with probes carrying a zero value (CS0) under congestion. In contrast, routers at around 2% of these links increase the delay by a comparable amount under congestion, uniformly for EF, AF42 and CS1.

Communication between two Internet hosts using parallel connections may result in unwanted interference between the connections. In this dissertation, we propose a sender-side solution to address this problem by letting the congestion controllers of the different connections collaborate, correctly taking congestion control logic into account. Real-life experiments and simulations show that our solution works for a wide variety of congestion control mechanisms, provides great flexibility when allocating application traffic to the connections, and results in lower queuing delay and less packet loss.

When multiple congestion controlled flows traverse the same network path, their resulting rate is usually an outcome of their competition at the bottleneck. The WebRTC / RTCWeb suite of standards for inter-browser communication is required to allow prioritization. This is addressed by our previously presented mechanism for coupled congestion control, called the Flow State Exchange (FSE). Here, we present our first simulation results using two mechanisms that have been proposed for IETF standardization: Google Congestion Control (GCC) and Network-Assisted Dynamic Adaptation (NADA). These two mechanisms exhibit aspects that allow us to use a simpler “passive” algorithm in our FSE. Passive coupling allows a less time-constrained request-response style of signaling between congestion control mechanisms and the FSE, which enables the FSE to run as a stand-alone management tool.