{"id":"204c961d-451a-4dc8-927f-5499014c74ea","arxiv_id":"2509.07338","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"PSketch combines an exact hash table for priority flows and a multi-layer sketch pipeline to report top-k elephant flows and retransmissions at line rate in eBPF on commodity Linux.","lead":"A new Linux eBPF-based monitoring tool, PSketch, tracks chosen high-priority network flows exactly while approximating the largest \"elephant\" flows with compact sketches. It aims to give operators precise in-kernel telemetry, including TCP retransmission rates, without specialized switch hardware.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Priority-path losslessness is untested under its own precondition: evaluation installs priority 5-tuples before replay, so reported 100% priority recall cannot support the general 'lossless' claim for flows that arrive before controller insertion.","rationale":"Reader's verdict was CONDITIONAL; my concern reinforces it rather than overturning it. The attack is load-bearing because the abstract's 'ensures lossless tracking' is the headline contribution, and the only evaluation that supports it assumes oracle-level prior knowledge. It is not an ad hominem or a consensus disagreement; it is an internal gap between the stated precondition in §III.A and the real-time deployment scenario implied by the title. The fix is straightforward: either (a) disclose the precondition prominently and scope the claim to controller-orchestrated flows, or (b) evaluate the system under dynamic insertion delay. Because this is addressable and does not invalidate the sketch mechanism itself, the appropriate verdict remains CONDITIONAL. I agree with the reader that this is the weakest assumption; the retransmission threshold issue is real but secondary, and this concern is more central to the 'lossless' claim.","tokens_in":8447,"tokens_out":8235,"duration_ms":102775,"concrete_test":"Run the same CAIDA replay but delay installation of each priority flow's 5-tuple until after a controlled fraction of that flow's packets (e.g., 0%, 1%, 5%, 10%) have already passed through the sketch path; use the same top-k settings and ground truth. If priority packet recall or retransmission recall falls measurably below 100%/97% for any nonzero delay, the 'lossless' claim is conditional on perfect a priori knowledge, not a system property. A second control: install priority tuples only after the controller observes the flow's first packet via a user-space sample, measuring the additional recall gap.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is 'lossless tracking of high-priority flows via a hash-based table.' For that to hold, §III.A requires that 'the five-tuple of each priority flow must be inserted into the priority table through the controller' before the flow's packets are processed. The evaluation (§V.A) makes this condition trivially true by selecting 10 priority flows from ground-truth heavy flows in the offline CAIDA trace and installing them before tcpreplay begins. The paper itself concedes the difficulty: §III.A states 'a major challenge arises in acquiring the complete five-tuple details in advance.' The gRPC confirmation mechanism only covers flows whose applications can wait for tuple installation; for externally identified priority flows (anomaly alerts, first-seen DML jobs), the first packets take the sketch path and can be evicted or approximated. Thus the reported 100% priority packet recall and 97.2–98.6% retransmission recall are upper bounds under an oracle, not evidence for losslessness in live operation. Since 'lossless high-priority tracking' is the paper's differentiator, this mismatch between the claim and the test is the load-bearing weakness.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"PSketch proposes an eBPF-based in-kernel flow-monitoring architecture that combines an exact BPF_HASH priority table with a sketch pipeline (heavy-flow table, linear counter, and a 3-layer Count-Min Sketch) for top-k and retransmission telemetry. The paper claims lossless tracking of high-priority flows, 96.0% top-k detection accuracy, 96.4% retransmission recall, and only 0.7% throughput degradation on replayed CAIDA 2019 traces at 10 Gbps. The evaluation is carried out on FABRIC testbed VMs with tcpreplay and uses Wireshark/Tshark-derived ground truth.","tokens_in":8751,"tokens_out":7091,"duration_ms":79788,"significance":"If the claims are substantiated, PSketch would be a practically useful step toward in-kernel flow monitoring without programmable-switch hardware. The hybrid design is intuitive, the use of commodity Linux eBPF is realistic, and the paper makes an effort to release code and evaluate on real CAIDA traces, which are commendable. However, the main quantitative claims are currently under-supported: the top-k accuracy metric is not precisely defined, the priority-flow evaluation is conducted under an oracle precondition, and the retransmission detector is a simplified heuristic with no sensitivity analysis. The architecture is plausible, but the evidence as presented does not yet establish the abstract's headline numbers.","major_comments":[{"comment":"The headline metric \"Top-k Flow Detection Accuracy\" is never defined. The text only says it \"measures how accurately PSketch identifies the top-k elephant flows by packet volume compared to ground truth.\" A reader cannot tell whether 96% is the fraction of ground-truth top-k flows present in PSketch's output, the precision of reported flows, a rank-based Jaccard similarity, or something else. Since this is the central quantitative claim, the metric must be specified precisely, and because the paper says experiments were run 10 times, Table 1 should report variance or confidence intervals rather than only point estimates.","section":"§V.B, Table 1"},{"comment":"The \"lossless tracking of high-priority flows\" claim is only tested under an oracle: the controller installs the 10 priority 5-tuples in the BPF_HASH map before tcpreplay begins, and the flows are selected from ground-truth heavy flows. The paper itself notes the \"major challenge\" of obtaining five-tuples in advance and proposes a gRPC confirmation mechanism, but no experiment exercises flows that arrive before or during controller insertion. Consequently, the reported 100% priority packet recall is an upper bound for the favorable case and does not support the general lossless claim. Please either scope the claim to flows whose tuples are installed before the first packet, add a dynamic-insertion experiment (e.g., install tuples after a fraction of the flow's packets have been processed), or quantify the insertion-latency budget needed to preserve losslessness.","section":"§III.A, §V.A"},{"comment":"The retransmission detector does not maintain a true next-expected-sequence-number state: it overwrites entry.exp_seq with the current packet's sequence number (the pseudocode uses the undefined p.exp_seq) instead of advancing by payload length, and it does not model ACKs, out-of-order segments, or loss. The only guard against TCP reordering is the hand-set 3 ms timestamp threshold, for which no sensitivity analysis is given. The reported 90–96% retransmission recall is therefore not well grounded. The evaluation should compare the heuristic against ground truth under controlled reordering and loss, or the claims should be limited to \"sequence-decrease events\" rather than retransmissions.","section":"§III.B, Algorithm 1"},{"comment":"The collision/eviction and flow-reconstruction mechanism is underspecified and internally unclear. When a slot in the heavy-flow table is replaced, the evicted flow's 5-tuple is overwritten and no separate key list is maintained; the CMS stores only per-bucket counters, not flow keys. Thus the described reconstruction (\"if kick_flag is set to 1, recompute the CMS indices ... take the minimum ... merged with values in the heavy flow table\") cannot recover statistics for a flow that has already been evicted, because its key is gone. In Algorithm 1, the CMS update branch after setting kicked references \"old stats,\" but those old statistics are not defined at that point. This makes the top-k per-flow packet-count recall numbers difficult to interpret.","section":"§III.B–III.E, Algorithm 1"}],"minor_comments":[{"comment":"Typographical errors: \"degration\" should be \"degradation\" in the abstract; \"statics\" appears where \"statistics\" is intended.","section":"Abstract and §I"},{"comment":"The sentence \"In the camera-ready version, we will clarify the original rationale of our controller module...\" is not appropriate for a submitted manuscript; either provide that clarification now or remove the sentence.","section":"§III.A"},{"comment":"Trace details are incomplete: specify which CAIDA 2019 dataset (date, duration, anonymization level), number of packets, and replay parameters. The phrase \"volume of input elephant flows is selectively adjusted to 50, 100, and 150\" is ambiguous; if these are k values, state so explicitly.","section":"§V.A"},{"comment":"No confidence intervals or standard deviations are reported despite the statement that each experiment was run 10 times; these should be added.","section":"Table 1"},{"comment":"The symbol p.exp_seq is undefined; presumably it should be p.seq or a payload-aware expected sequence. Also, notation is inconsistent between \"VOTE_THRE\" and \"VOTE THRE\" in the prose and pseudocode.","section":"Algorithm 1"},{"comment":"Several references appear incomplete or with placeholder author lists (e.g., [13], [14]). Please verify and complete all bibliographic entries.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper has a plausible design and honest limitations, but the manuscript reads like a work in progress (e.g., the \"camera-ready\" sentence and incomplete references). The most important missing piece is a baseline comparison against prior eBPF sketch systems such as Miano et al. and SketchFlow, especially because the paper claims to be the \"first\" in-kernel priority-aware framework. I would also ask the editor to require the authors to either release the full experimental pipeline or clearly state which parts of the evaluation are reproducible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This paper is a reasonable systems integration: a BPF_HASH priority table for exact tracking of selected flows, a voting-based heavy-hitter table, a 3-layer Count-Min Sketch, a linear counter, and an in-kernel retransmission heuristic. The genuinely new part is putting these together in eBPF and estimating retransmissions per flow from sequence numbers. The writing is clear, the design is plausible, and the authors cite the prior eBPF sketch work (Miano, SketchFlow, eBPFmon) rather than ignoring it. Code is on GitHub, though incomplete. I give credit for that.\n\nThe soft spots are real but mostly fixable. The biggest one is that the central claim — lossless tracking of high-priority flows — is not actually tested. The evaluation installs priority 5-tuples from the ground-truth trace before replay, so the 100% priority recall is an upper bound under oracle conditions. The paper itself admits that acquiring five-tuples in advance is a major challenge, and its gRPC confirmation only works for flows that can wait. Anomaly-detected or first-seen DML flows would hit the sketch path first, where they can be evicted or approximated. So the differentiator is unproven in live operation. This needs a live-traffic experiment, or at least a sensitivity analysis simulating delayed insertion.\n\nThe quantitative claims are also under-supported. \"Top-k detection accuracy\" is never defined. Table 1 gives point estimates from 10 runs with no variance, no comparison against prior eBPF sketches, and no baseline beyond PSketch on/off. The 3 ms retransmission threshold and VOTE_THRE are hand-set with no sensitivity analysis. These are addressable, and the conclusion even says the retransmission logic is simplified, so the authors are not hiding it.\n\nThe central sketch pipeline itself is standard and likely works as described. The retransmission heuristic is a heuristic, and the paper treats it that way. The \"first\" claim is overstated — the paper's own related work shows priority-aware eBPF telemetry exists — but that's a wording issue.\n\nThis paper deserves a serious referee. The idea is timely and the implementation is non-trivial. But I would not cite it until the metrics are defined, variance is reported, baselines are added, and the priority-insertion precondition is stress-tested. Reading-group material? Maybe, if the group wants to debate what counts as evidence in systems papers.","headline":"A plausible eBPF sketch integration with real code, but the headline 'lossless priority' claim is only tested under an oracle precondition and the accuracy metrics are under-specified.","tokens_in":9263,"tokens_out":1735,"would_cite":false,"duration_ms":21685,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"PSketch claims the first in-kernel, priority-aware sketch monitor: exact for chosen flows, approximate for everything else.","keywords":["eBPF","priority-aware monitoring","sketch data structures","in-kernel telemetry","TCP retransmission","top-k elephant flows","Count-Min sketch","flow monitoring"],"falsifier":"Replay a trace with the priority table left empty and compare ground-truth packet recall for the flows the experiment would otherwise designate as priority; if those flows are still counted exactly, the pre-installation assumption is unnecessary, and if they are not, the headline priority guarantee depends on controller knowledge.","tokens_in":8353,"feed_emoji":"📊","tokens_out":6475,"duration_ms":72560,"temperature":0.7,"pith_summary":"PSketch claims to be the first priority-aware flow-monitoring framework that runs entirely inside the Linux kernel using eBPF, so it needs no programmable switch hardware. It keeps an exact hash table for a small set of high-priority flows while routing all other traffic through a sketch pipeline that estimates top-k elephant flows, per-flow packet counts, retransmission counts, and total flow cardinality. On 10 Gbps backbone traces it reports about 96% top-k detection accuracy, 100% packet recall for priority flows, above 96% retransmission recall, and throughput loss below 1.1%. If these numbers hold, PSketch offers operators a cheap, deployable way to combine lossless monitoring of critical flows with approximate visibility of the rest.","feed_headline":"Priority-aware flow monitor runs inside the Linux kernel","feed_subtitle":"Selected flows get lossless counts; everyone else is approximated with a sketch pipe in eBPF.","key_machinery":"The central machinery is a two-path packet classifier. The priority path is a BPF_HASH table keyed by flow 5-tuples, giving O(1) exact accounting. The approximate path is a sketch pipe: a fixed heavy-flow BPF_ARRAY whose Jenkins-hashed slots hold per-flow counters and a negative_counter; when negative_counter times VOTE_THRE reaches the slot's packet_count, the resident flow is evicted and its stats are forwarded to the sketch layers. A linear counter (m-bit array with the -m ln(V/m) estimator) estimates distinct flows, and a three-layer Count-Min sketch (three BPF arrays of 500 entries) accumulates packet and retransmission counts; reconstruction takes the minimum of the three CMS counters","core_discovery":"The paper argues that priority-aware monitoring can live entirely in the kernel by splitting traffic into two paths. A hash-based priority table matches each packet's 5-tuple against installed high-priority flow keys; matched flows are counted exactly, with TCP retransmissions detected by comparing sequence numbers under a 3 ms timestamp threshold. Everything else goes through a sketch pipe: a heavy-flow table with a voting eviction rule, a linear counter for cardinality, and a three-layer Count-Min sketch that also tracks retransmission counts; a kick flag and min-of-three reconstruction reassemble statistics for flows evicted from the heavy table. Evaluation on 10 Gbps backbone traces repo","pith_inferences":["Editorial inference: the priority mechanism is a policy hook, not a detector; a natural extension is to auto-promote flows that the sketch path flags as growing, turning the system into a closed loop.","Editorial inference: the 3 ms retransmission threshold is effectively a reordering-versus-loss classifier, and its behavior under delay spikes or multipath reordering is untested—the likeliest place the reported recall could degrade outside the trace workload.","Editorial inference: the same split—exact table for a chosen subset, sketch for the rest—could apply to other kernel-level count streams such as syscalls, storage I/O, or container traffic where a few keys deserve lossless accounting."],"forward_implications":["Any Linux 5.4+ host can offer priority-aware and top-k flow telemetry without programmable switches, moving monitoring from core switches to hosts and virtual machines.","Operators can configure exact accounting for a few critical flows (for example, distributed-training jobs) while keeping approximate visibility over all remaining traffic at under 1.1% throughput cost.","Retransmission telemetry becomes available per priority flow and per top-k flow from the same packet path, providing a congestion signal without separate middleboxes.","The reported recall numbers establish a concrete accuracy baseline for comparing future in-kernel sketch designs."],"supporting_citations":[{"why":"Supplies the demonstration that sketch algorithms can run efficiently inside eBPF, establishing feasibility for in-kernel sketching.","marker":"[13]"},{"why":"Supplies the in-kernel Count-Min sketch DDoS detection baseline that PSketch extends with priority awareness.","marker":"[14]"},{"why":"Supplies the hybrid-sketch flow-size estimation design whose accuracy-versus-memory trade-offs PSketch builds on.","marker":"[15]"},{"why":"Supplies the priority-aware adaptive eBPF telemetry work that PSketch extends with exact priority handling.","marker":"[18]"},{"why":"Supplies the linear-counter estimator formula used for cardinality estimation.","marker":"[24]"},{"why":"Supplies the Count-Min sketch data structure and its min-of-hashes estimator used in the three-layer pipeline.","marker":"[25]"},{"why":"Supplies the backbone traffic traces used in the evaluation.","marker":"[12]"},{"why":"Supplies the SDN and hardware limitations that motivate moving sketch monitoring into the kernel.","marker":"[7]"}],"fun_headline_variants":["Kernel sketch pipe tracks top flows with 96% accuracy","Priority-aware eBPF monitor splits exact and approximate paths","In-kernel flow monitoring: exact for VIPs, sketch for rest","eBPF sketch cuts flow monitoring overhead to 0.7%"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The lossless-priority result holds only if the exact five-tuples of priority flows are installed in the priority table before those flows send packets; live traffic with no such pre-installed list bypasses the exact path.","fun_headline_variants_meta":{"raw":{"variants":["Kernel sketch pipe tracks top flows with 96% accuracy","Priority-aware eBPF monitor splits exact and approximate paths","In-kernel flow monitoring: exact for VIPs, sketch for rest","eBPF sketch cuts flow monitoring overhead to 0.7%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000652,"raw_usage":{"total_tokens":2782,"prompt_tokens":654,"completion_tokens":2128,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":398,"completion_tokens_details":{"reasoning_tokens":2054}},"tokens_in":398,"tokens_out":2128,"duration_ms":17517,"temperature":1.0,"reasoning_tokens":2054,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T22:21:42.312489+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Replay a trace with the priority table left empty and compare ground-truth packet recall for the flows the experiment would otherwise designate as priority; if those flows are still counted exactly, the pre-installation assumption is unnecessary, and if they are not, the headline priority guarantee depends on controller knowledge.","supporting_citations":[{"cited_title":"Fast and memory-efficient sketches in the ebpf virtual machine,","cited_arxiv_id":null,"evidence_quote":"Supplies the demonstration that sketch algorithms can run efficiently inside eBPF, establishing feasibility for in-kernel sketching."},{"cited_title":"Kernel-level count-min sketch for ddos detection with ebpf,","cited_arxiv_id":null,"evidence_quote":"Supplies the in-kernel Count-Min sketch DDoS detection baseline that PSketch extends with priority awareness."},{"cited_title":"Sketchflow: Efficient flow size estimation with hybrid sketches,","cited_arxiv_id":null,"evidence_quote":"Supplies the hybrid-sketch flow-size estimation design whose accuracy-versus-memory trade-offs PSketch builds on."},{"cited_title":"ebpfmon: Priority-aware adaptive telemetry with ebpf,","cited_arxiv_id":null,"evidence_quote":"Supplies the priority-aware adaptive eBPF telemetry work that PSketch extends with exact priority handling."},{"cited_title":"A linear- time probabilistic counting algorithm for database applications,","cited_arxiv_id":null,"evidence_quote":"Supplies the linear-counter estimator formula used for cardinality estimation."},{"cited_title":"An improved data stream summary: the count-min sketch and its applications,","cited_arxiv_id":null,"evidence_quote":"Supplies the Count-Min sketch data structure and its min-of-hashes estimator used in the three-layer pipeline."},{"cited_title":"The caida ucsd anonymized internet traces 2019,","cited_arxiv_id":null,"evidence_quote":"Supplies the backbone traffic traces used in the evaluation."},{"cited_title":"Mc-sketch: Enabling heterogeneous net- work monitoring resolutions with multi-class sketch,","cited_arxiv_id":null,"evidence_quote":"Supplies the SDN and hardware limitations that motivate moving sketch monitoring into the kernel."}],"review_version":1}