Retroactive Packet Sampling for Traffic Receipts

Abstract

Is it possible to design a packet-sampling algorithm that prevents the network node that performs the sampling from treating the sampled packets preferentially? We study this problem in the context of designing a "network transparency" system. In this system, networks emit receipts for a small sample of the packets they observe, and a monitor collects these receipts to estimate each network's loss and delay performance. Sampling is a good building block for this system, because it enables a solution that is flexible and combines low resource cost with quantifiable accuracy. The challenge is cheating resistance: when a network's performance is assessed based on the conditions experienced by a small traffic sample, the network has a strong incentive to treat the sampled packets better than the rest. We contribute a sampling algorithm that is provably robust to such prioritization attacks, enables network performance estimation with quantifiable accuracy, and requires minimal resources. We confirm our analysis using real traffic traces.

BEAT: Blockchain-Enabled Accountable and Transparent Infrastructure Sharing in 6G and Beyond

“…When the governance confirms that all the devices are assigned as per the SLA, further investigations of throughput degradation due to problems such as link failure and packet drop/loss should be carried out. As BEAT is focused fundamentally on resource assignment, service degradation due to other copiously discussed factors such as packet loss and delay [17] [27], prioritisation attacks [28] and devices intentionally dropping packet [29] are out of scope for this work, and we leave these details for future enhancements. Nevertheless, the throughput and packet loss per device can still be calculated with the timestamps in the receipts (ts) and proofs (tr).…”

dDrops: Detecting silent packet drops on programmable data plane

“…ERSPAN [33,34,11] and INT [16,35] can potentially achieve full-visibility, but suffer from granularity-cost trade-off. Their bandwidth and processing overhead grow quickly with the scale of the network.…”

BEAT: Blockchain-Enabled Accountable and Transparent Infrastructure Sharing in 6G and Beyond

“…When the governance confirms that all the devices are assigned as per the SLA, further investigations of throughput degradation due to problems such as link failure and packet drop/loss should be carried out. As BEAT is focused fundamentally on resource assignment, service degradation due to other copiously discussed factors factors such as packet loss and delay [17] [22], prioritisation attacks [23] and devices intentionally dropping packet [24] are out of scope for this work, and we leave these details for future enhancements. Nevertheless, the throughput and packet loss per device can still be calculated with the timestamps in the receipts (𝑡𝑠) and proofs (𝑡𝑟).…”