-
Privacy Measurement in Tabular Synthetic Data: State of the Art and Future Research Directions
Authors:
Alexander Boudewijn,
Andrea Filippo Ferraris,
Daniele Panfilo,
Vanessa Cocca,
Sabrina Zinutti,
Karel De Schepper,
Carlo Rossi Chauvenet
Abstract:
Synthetic data (SD) have garnered attention as a privacy enhancing technology. Unfortunately, there is no standard for quantifying their degree of privacy protection. In this paper, we discuss proposed quantification approaches. This contributes to the development of SD privacy standards; stimulates multi-disciplinary discussion; and helps SD researchers make informed modeling and evaluation decis…
▽ More
Synthetic data (SD) have garnered attention as a privacy enhancing technology. Unfortunately, there is no standard for quantifying their degree of privacy protection. In this paper, we discuss proposed quantification approaches. This contributes to the development of SD privacy standards; stimulates multi-disciplinary discussion; and helps SD researchers make informed modeling and evaluation decisions.
△ Less
Submitted 29 November, 2023;
originally announced November 2023.
-
Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All
Authors:
Koen De Schepper,
Olga Albisser,
Olivier Tilmans,
Bob Briscoe
Abstract:
On the Internet, sub-millisecond queueing delay and capacity-seeking have traditionally been considered mutually exclusive. We introduce a service that offers both: Low Latency Low Loss Scalable throughput (L4S). When tested under a wide range of conditions emulated on a testbed using real residential broadband equipment, queue delay remained both low (median 100--300 $μ$s) and consistent (99th pe…
▽ More
On the Internet, sub-millisecond queueing delay and capacity-seeking have traditionally been considered mutually exclusive. We introduce a service that offers both: Low Latency Low Loss Scalable throughput (L4S). When tested under a wide range of conditions emulated on a testbed using real residential broadband equipment, queue delay remained both low (median 100--300 $μ$s) and consistent (99th percentile below 2 ms even under highly dynamic workloads), without compromising other metrics (zero congestion loss and close to full utilization). L4S exploits the properties of `Scalable' congestion controls (e.g., DCTCP, TCP Prague). Flows using such congestion control are however very aggressive, which causes a deployment challenge as L4S has to coexist with so-called `Classic' flows (e.g., Reno, CUBIC). This paper introduces an architectural solution: `Dual Queue Coupled Active Queue Management', which enables balance between Scalable and Classic flows. It counterbalances the more aggressive response of Scalable flows with more aggressive marking, without having to inspect flow identifiers. The Dual Queue structure has been implemented as a Linux queuing discipline. It acts like a semi-permeable membrane, isolating the latency of Scalable and `Classic' traffic, but coupling their capacity into a single bandwidth pool. This paper justifies the design and implementation choices, and visualizes a representative selection of hundreds of thousands of experiment runs to test our claims.
△ Less
Submitted 2 September, 2022;
originally announced September 2022.
-
Resolving Tensions between Congestion Control Scaling Requirements
Authors:
Bob Briscoe,
Koen De Schepper
Abstract:
Low Latency, Low Loss Scalable throughput (L4S) is being proposed as the new default Internet service. L4S can be considered as an `incrementally deployable clean-slate' for new Internet flow-rate control mechanisms. Because, for a brief period, researchers are free to develop host and network mechanisms in tandem, somewhat unconstrained by any pre-existing legacy.
Scaling requirements represent…
▽ More
Low Latency, Low Loss Scalable throughput (L4S) is being proposed as the new default Internet service. L4S can be considered as an `incrementally deployable clean-slate' for new Internet flow-rate control mechanisms. Because, for a brief period, researchers are free to develop host and network mechanisms in tandem, somewhat unconstrained by any pre-existing legacy.
Scaling requirements represent the main constraints on a clean-slate design space. This document confines its scope to the steady state. It aims to resolve the tensions between a number of apparently conflicting scalability requirements for L4S congestion controllers. It has been produced to inform and provide structure to the debate as researchers work towards pre-standardization consensus on this issue.
This work is important, because clean-slate opportunities like this arise only rarely and will only be available briefly---for roughly one year. The decisions we make now will tend to dirty the slate again, probably for many decades.
△ Less
Submitted 16 April, 2019;
originally announced April 2019.
-
Scaling TCP's Congestion Window for Small Round Trip Times
Authors:
Bob Briscoe,
Koen De Schepper
Abstract:
This memo explains that deploying active queue management (AQM) to counter bufferbloat will not prevent TCP from overriding the AQM and building large queues in a range of not uncommon scenarios. This is a brief paper study to explain this effect which was observed in a number of low latency testbed experiments.
To keep its queue short, an AQM drops (or marks) packets to make the TCP flow(s) tra…
▽ More
This memo explains that deploying active queue management (AQM) to counter bufferbloat will not prevent TCP from overriding the AQM and building large queues in a range of not uncommon scenarios. This is a brief paper study to explain this effect which was observed in a number of low latency testbed experiments.
To keep its queue short, an AQM drops (or marks) packets to make the TCP flow(s) traversing it reduce their packet rate. Nearly all TCP implementations will not run at less than two packets per round trip time (RTT). 2pkt / RTT need not imply low bit-rate if the RTT is small. For instance, it represents 2Mb/s over a 6ms round trip. When a few TCP flows share a link, in certain scenarios, including regular broadband and data centres, no matter how much the AQM signals to the flows to keep the queue short, they will not obey, because it is impossible for them to run below this floor. The memo proposes the necessary modification to the TCP standard.
△ Less
Submitted 16 April, 2019;
originally announced April 2019.
-
Insights from Curvy RED (Random Early Detection)
Authors:
Bob Briscoe,
Koen De Schepper
Abstract:
Active queue management (AQM) drops packets early in the growth of a queue, to prevent a capacity-seeking sender (e.g. TCP) from kee** the buffer full. An AQM can mark instead of drop** packets if they indicate support for explicit congestion notification (ECN). Two modern AQMs (PIE and CoDel) are designed to keep queuing delay to a target by drop** packets as load varies. This memo uses Cur…
▽ More
Active queue management (AQM) drops packets early in the growth of a queue, to prevent a capacity-seeking sender (e.g. TCP) from kee** the buffer full. An AQM can mark instead of drop** packets if they indicate support for explicit congestion notification (ECN). Two modern AQMs (PIE and CoDel) are designed to keep queuing delay to a target by drop** packets as load varies. This memo uses Curvy RED and an idealised but sufficient model of TCP traffic to explain why attempting to keep delay constant is a bad idea, because it requires excessively high drop at high loads. This high drop itself takes over from queuing delay as the dominant cause of delay, particularly for short flows. At high load, a link is better able to preserve reasonable performance if the delay target is softened into a curve rather than a hard cap. The analysis proves that the same AQM can be deployed in different parts of a network whatever the capacity with the same optimal configuration. A surprising corollary of this analysis concerns cases with a highly aggregated number of flows through a bottleneck. Although aggregation reduces queue variation, if the target queuing delay of the AQM at that bottleneck is reduced to take advantage of this aggregation, TCP will still increase the loss level because of the reduction in round trip time. The way to resolve this dilemma is to overprovision (a formula is provided). Nonetheless, for traffic with ECN enabled, there is no harm in an AQM holding queuing delay constant or configuring an AQM to take advantage of any reduced delay due to aggregation without over-provisioning. Recently, the requirement of the ECN standard that ECN must be treated the same as drop has been questioned. The insight that the goals of an AQM for drop and for ECN should be different proves that this doubt is justified.
△ Less
Submitted 15 April, 2019;
originally announced April 2019.
