NOTES FROM THE WORKBENCH

Show your working.

Small, reproducible studies of how content delivery behaves.

The lab is taking shape.

These are draft protocols. Measured results will be published when the test infrastructure is ready.

Seoul delivery study

Planned

Start with one identified residential connection and a small set of CDN plans. Add KT, SK Broadband, and LG U+ connections as measurement points become available, keeping each connection’s results separate.

Test content
Serve the same small static file from an origin we control through each CDN. Match the object size, cache policy, and client settings.
What to collect
Record the responding edge when identifiable, confirm cache HIT status, and collect TTFB samples at several times of day. Keep IPv4 and IPv6 samples separate.
What to publish
Include the provider and plan, ISP and ASN, connection type, test region, dates, sample count, failures, and median / p95 TTFB. Describe connection reuse and protocol settings with the results.
Scope of a result
A residential connection and a data-center server represent different access paths. Label each measurement point and preserve uncertainty when an edge cannot be identified.
Seoul locations & plan terms
01Edge selectionWhere does this request actually land?Protocol draft
  1. Record the CDN product, plan, and test hostname.
  2. Identify the access ASN, resolver, IP version, and vantage point.
  3. Use documented edge identifiers where available; preserve uncertainty.
  4. Retain a representative route and record meaningful changes.
How observations are reported
02Warm-cache deliveryWhat happens after the content is cached?Protocol draft
  1. Use the same object size and cache policy across products.
  2. Confirm a cache hit before including a sample.
  3. Keep connection reuse, protocol, and test timing consistent.
  4. Publish the sample count, failures, and TTFB distribution.
How observations are reported
03Purge propagationWhen does an update reach the edge?Protocol draft
  1. Publish a versioned object, then prime the test edges.
  2. Timestamp the purge request and acknowledgment.
  3. Observe when each edge serves the new version.
  4. Describe the purge API, polling interval, and any uncertainty.
How observations are reported