Research

Research Design and Reporting

Wiki home

Project overview · Concepts · Research · Publications · Documentation policy

Research Focus

Topology and connectivity. Examine how peer connections form and evolve, and how overlay structure relates to communication behavior.

Broadcast performance. Evaluate message delivery, propagation latency, duplicate reception, and protocol overhead under different configurations.

Network dynamics. Investigate how peer joins and departures, communication delays, packet loss, and other network conditions affect connectivity and dissemination.

These are research questions, not a list of measurements or protocols implemented by every version. Use the v3 architecture guide and scenario reference to establish which mechanisms the current implementation supports.

Experiment Cycle

An experiment connects a research question to evidence. The cycle below is a research workflow; it is not an executable scenario schema or an assertion that every step is automated.

flowchart LR
    Question["Frame a question and baseline"]
    Design["Choose population, workload, conditions, and measurement rules"]
    Prepare["Prepare execution resources and record configuration"]
    Run["Execute peer activity and collect evidence"]
    Assess["Check completion, observation gaps, and comparability"]
    Compare["Compare repetitions and report results"]

    Question --> Design --> Prepare --> Run --> Assess --> Compare
    Assess -->|"repeat with a recorded setup"| Prepare
    Compare -->|"refine the question"| Question

Loading

Record planned inputs and observed outcomes separately. Reusing a configuration or random seed helps reproduce an experimental setup, but it does not guarantee identical execution timing, topology, or message delivery. Use the research reporting principles to define the comparison and the v3 scenario guide to express supported actions.

From Research Question to Experiment

Dimension	What to decide and record
Comparison	The baseline, the variable being changed, and the hypothesis being evaluated. Separate a protocol change from a change in workload or available resources.
Population and membership	Which peers publish, subscribe, join, and depart; whether the question concerns the initial population or sessions that remain eligible during observation.
Workload and conditions	Message size and timing, peer activity, imposed network conditions, host placement, and shared-resource constraints.
Execution resources and placement	Host inventory and identifiers, configured capacities and exceptions, placement policy, observed occupancy/readiness, and the timing of configuration changes during execution.
Observation	The meaning of a graph edge or event, the collection interval, the delivery deadline, and how clock uncertainty and missing reports affect interpretation.
Repetition and provenance	Software revision, input configuration, randomization inputs, execution environment, run identifiers, and retained evidence for each repetition.
Failure and recovery	Completed, failed, canceled, and interrupted iterations; the recovery mode; relationships between original attempts and retries; and which results enter the comparison and why.

An overlay describes protocol relationships between peers. Host placement describes where those peers execute, and the physical network provides their underlying connectivity. These views answer different questions: a placement diagram does not establish a protocol topology, and a reported protocol relationship does not by itself prove application delivery.

Experimental Reporting Principles

• Define the eligible receiver population and observation window when reporting delivery under churn.
• Choose eligibility independently of delivery success. Report departures and population coverage so a survivor-only result is not mistaken for delivery to the original population.
• Distinguish delivery, latency, duplicate reception, and protocol overhead rather than combining them into one efficiency value.
• State the unit and aggregation rule: per message, receiver, receiver-message pair, RPC, identifier reference, or byte. Identify whether latency includes only successful deliveries.
• Distinguish direct measurements, metadata estimates, model predictions, and fixed reference data. Report evidence, assumptions, and unclassified coverage with estimates; correlation or a baseline difference alone does not establish a forwarding cause or causal effect.
• Distinguish a configured rate limit, observed bytes/throughput, and physical link capacity. State the measurement layer and direction, including whether both endpoints of one transfer are counted.
• Report missing or uncertain observations explicitly so telemetry gaps are not interpreted as protocol failure.
• Record the implementation version or commit, scenario, configuration, and randomization inputs needed to reproduce an experiment.
• Separate an observed result from a configured target and a historical validation record from a check performed on the current revision. Repeated inputs do not guarantee identical distributed execution.

These are project-level principles. Exact event schemas, formulas, defaults, and export behavior are versioned implementation contracts.

For current v3 measurements and estimates, use experiment metrics and bandwidth measurement. Saved-result visualization describes repeat comparisons and image/data exports; API defines analysis jobs and log fields. Check definition version, population, units, and aggregation before comparing values with the same metric name.

Placement, Timing, and Recovery in Reported Results

Host capacity is a Peer-count limit, not a resource measurement. Setting capacities to 100:50 and placing 50:25 Peers does not establish the same ratio of CPU or memory use. Record host occupancy, Peer roles, and resource load together; distinguish periods before and after a capacity adjustment. Even identical configured limits can yield different placement and waiting times because other experiments or containers awaiting cleanup occupy slots.

Distinguish requested join intervals from observed creation and readiness times. Waiting for free slots, container startup, delayed work, and observation gaps can change the observed population. Reporting the difference between target and observed population helps separate scheduling delays from the protocol effects of churn.

Record continuation and retry as attempt history. Keeping completed iterations and running the remaining work differs from making a new attempt at a failed iteration. Retaining only successful retries, or counting multiple attempts as independent repetitions, changes the comparison population and failure rate. Report the iteration/attempt selection rule, failure and interruption counts, and configuration before and after recovery.

See capacity and placement, retained results, and execution and recovery for v3's application and recovery rules. Compare browser reconnection or missing dashboard observations with saved execution state and records before classifying an experiment as failed.

Measurement Background

The HyParView technical report, §2.5 and §5.2 evaluates dissemination in terms of active nodes and examines behavior after failures. It provides context for asking about delivery among surviving participants. Our interpretation is that such a question must state its population explicitly; it does not justify excluding only departed receivers that failed to receive.

Pongthawornkamol et al., ICAC 2013, §2.2 and §3.2.2–3 connect reliability with delivery before an event deadline and weight publisher-subscriber flows by event rates. Their model concerns broker and link failures, which differs from tracking receiver subscription sessions under churn.

These works provide measurement context; they are not K-P2PLab publications or claims that those protocols are implemented here. K-P2PLab's particular window, session-evidence, weighting, uncertainty, and duplicate-counting rules are implementation design choices. The v3 metrics guide owns their exact definitions and limitations.

Publications

See platform publications and studies using K-P2PLab.

Platform Publications

See platform publications.

Research Using K-P2PLab

See studies using K-P2PLab.

Citing K-P2PLab

Follow the version-specific citation guidance and record the implementation commit used.

---

Korean translation: 한국어.