Concepts

Concepts and Architecture

Wiki home

Project overview · Concepts · Research · Publications · Documentation policy

This guide explains design intent and responsibilities that persist across versions. For concrete services, networks, and failure boundaries, see the v3 implementation architecture.

Design Principles

Principle	What it means
Central orchestration	Coordinate experiment execution, peer lifecycle operations, and result collection through a central control plane.
Multi-host execution	Distribute peer workloads across hosts according to their available capacity and placement policy.
Elastic experiment scale	Adjust execution resources and the peer population while observing both the requested scale and actual placement/readiness.
Real P2P execution	Run actual protocol implementations and exchange network traffic, rather than represent peers only as simulated entities.
Per-peer container isolation	Give each peer a separate container and network namespace, making the peer an individually managed experimental unit.

Container isolation separates peer execution and networking environments; it does not imply dedicated physical resources or eliminate contention on a shared host.

Conceptual Architecture

The testbed has three interacting responsibilities: experiment control, distributed peer execution, and observation. This view expands those responsibilities without prescribing a service layout.

flowchart TB
    Researcher["Researcher: question and comparison plan"]

    subgraph Control["Central experiment control"]
        Definition["Experiment definition: population, protocol, workload, conditions"]
        Resources["Host capacities and placement policy"]
        Coordination["Coordinate placement, timing, lifecycle, and workload actions"]
        State["Experiment state and execution progress"]
        Definition --> Coordination
        Resources --> Coordination
        Coordination --> State
    end

    subgraph Execution["Distributed execution: representative hosts and peer links"]
        direction LR
        subgraph HostA["Execution host A"]
            LocalA["Host-local workload management"]
            PeerA1["Isolated peer A1: protocol and application"]
            PeerA2["Isolated peer A2: protocol and application"]
            LocalA --> PeerA1
            LocalA --> PeerA2
        end
        subgraph HostB["Execution host B"]
            LocalB["Host-local workload management"]
            PeerB1["Isolated peer B1: protocol and application"]
            PeerB2["Isolated peer B2: protocol and application"]
            LocalB --> PeerB1
            LocalB --> PeerB2
        end
        PeerA1 <==>|"P2P traffic within a host"| PeerA2
        PeerA2 <==>|"P2P traffic across hosts"| PeerB1
        PeerB1 <==>|"P2P traffic within a host"| PeerB2
    end

    subgraph Observation["Observation and research analysis"]
        Evidence["Collect lifecycle, topology, protocol, and delivery evidence"]
        Records["Preserve experiment inputs and observed records"]
        Analysis["Interpret delivery, latency, duplicates, and overhead"]
        Results["Compare runs and report uncertainty"]
        Evidence --> Records --> Analysis --> Results
    end

    Researcher --> Definition
    Coordination -->|"assign work and conditions"| LocalA
    Coordination -->|"assign work and conditions"| LocalB
    LocalA -.->|"status and peer observations"| Evidence
    LocalB -.->|"status and peer observations"| Evidence
    Evidence -.->|"reported execution state"| State
    Definition -->|"experiment context"| Records
    State -.->|"progress"| Researcher
    Results -->|"inform the next experiment"| Researcher

Loading

Reading the arrows. Thin solid arrows describe instructions or the research workflow; thick bidirectional arrows describe experimental P2P traffic; dotted arrows describe observations. The illustrated hosts and peer links are examples, not a required host count, fixed topology, or full mesh. The P2P network is formed by the peers and their protocol relationships; it is not an additional central forwarding service.

Responsibility	Conceptual boundary
Experiment definition and control	Express the intended population, protocol settings, workload, timing, and conditions; coordinate their execution and track reported progress. Intended settings and observed behavior can differ.
Host-local execution	Turn assigned work into individually managed peer workloads and collect local execution reports. The mechanism and placement policy depend on the implementation.
Peer protocol execution	Discover and connect to other peers, maintain protocol relationships, and exchange experimental messages. A centrally requested workload action initiates peer activity; it does not make the controller a P2P relay.
Observation and records	Associate execution and protocol evidence with experiment context. Reports can be delayed or missing, so collected state is an observation rather than complete knowledge of the network.
Research analysis	Interpret measurements, compare runs, and report assumptions and uncertainty. This includes researcher work outside the testbed; the box does not promise an automated analysis service.

The separation above is logical. It does not guarantee separate processes, containers, physical networks, or fault domains for every box. Network conditions act on traffic within the chosen experimental scope, while shared host resources and the physical interconnect also affect the outcome. For concrete services, network attachments, supported controls, and measurement limits, see the v3 architecture guide.

Capacity and Workload Placement

An experiment's target Peer count, a host's admitted Peer limit, and the number of ready Peers describe different things. Capacity constrains admission; placement policy chooses execution locations within those limits. The implementation defines which reservations and resources awaiting cleanup count as occupied.

Hosts of different sizes can use capacity-proportional placement. A ratio of Peer counts does not guarantee the same ratio of CPU or memory use: observe resource load together with Peer roles and workloads. Record requested scale separately from actual placement and readiness as execution resources change. Elastic execution does not promise arbitrary scale or exact timing intervals.

v3 Agent capacity and placement defines startup defaults, per-Agent exceptions, a proportional-allocation example, application timing, and treatment of existing Peers.

---

Korean translation: 한국어.