2026 Halo-style global entry matrix
SCP/SFTP artifact p95, TCP windows & regional shunt sign-off

This note extends the DNS and SSH framing in GeoDNS, SSH latency & node matrix and the TTL or split-horizon discussion in Split-horizon vs GeoDNS & artifact p95, but narrows the lens to bulk transfer over SSH and TCP window scaling when runners in Japan, Korea, Hong Kong, Singapore, and US West exchange artifacts with registries that may live one ocean away. For edge-routed HTTPS plus SSH acceptance on US West versus Hong Kong or Singapore, keep Worker routing & SSH p95 open in another tab so marketing hostnames do not silently diverge from what CI actually uses.

Halo entry decision matrix (control plane vs artifact plane)

Use the matrix in design reviews before you standardise on a single “global” hostname for both humans and automation. Rows describe what you are optimising; columns tell you whether a Halo-style indirection is helping or hiding pain.

Routing choice (which PoP owns the bytes)

Routing choice here means the full chain: client resolver answer, TCP path to the remote Mac or bastion, and the onward path to the object store—not only which country flag appears in marketing. For SCP/SFTP, pick the PoP where (a) your builder runs, (b) the authoritative or replicated registry lives, and (c) your enterprise egress policy already allows bulk flows. If any leg differs, document it as a “relay hop” with its own latency budget instead of pretending GeoDNS solved physics.

Practical split: humans may land on a Halo hostname; CI should call artifacts.jp.example style endpoints that resolve inside the same metro as the runner. When Korea and Japan teams share one Singapore registry by policy, treat Singapore as the designed backhaul hub and size p95 against that hub—not against a fantasy direct Tokyo-to-Seoul short cut through the public internet.

Concurrent connections (avoid self-DDoS)

SCP and SFTP over OpenSSH multiplex many small files poorly when you open dozens of parallel sessions from the same CI host: each session pays handshakes and competes for kernel buffers. Cap concurrent transfers per runner (often 2–4 large streams, or one stream plus metadata) and raise limits only after you confirm the server’s MaxSessions, CPU, and disk can absorb the burst. On macOS builders, watch syslog for disk pressure; on Linux relays, watch ss retransmit counters.

If you rely on ControlMaster for many small files, remember it optimises connection setup—not cross-ocean bandwidth. Pair it with archiving (tar before copy) or rsync-style deltas where policy allows, so concurrency tuning maps to real bytes on the wire.

Checksums (trust but verify at p95 scale)

At multi‑gigabyte scale, “copy finished” without a cryptographic check is a lottery ticket. Standardise one algorithm per pipeline (sha256sum on both ends, or manifest files produced by your registry) and record digest, size, and elapsed seconds in the same log line as hostname and region ID. For SFTP through automation, prefer manifests signed by your build system over ad-hoc remote shell pipelines that are hard to replay during incidents.

When checksums disagree, treat it as a transport or storage incident first, not as “user error”: capture TCP retransmits on the relay, compare MTU paths, and only then rerun the transfer with a narrower concurrency window.

Failure retry (exponential backoff vs blast radius)

Retries must be bounded: exponential backoff with jitter, a maximum attempt count, and a circuit breaker when p95 crosses your budget for fifteen minutes. Never tight-loop reconnects against a shared bastion—that looks like an attack and burns file descriptors for everyone. For partial files, prefer resume primitives your toolchain already exposes (append-friendly SFTP servers, segmented HTTP downloads, or object-store multipart APIs) instead of blindly deleting and restarting multi‑hour copies.

Log retry reason codes (timeout, reset, digest_mismatch, quota) so postmortems can tell DNS flaps from congestion loss without re-running the transfer.

TCP window scaling, sysctl, and OpenSSH knobs (with boundaries)

High bandwidth-delay product paths need large enough send and receive windows that TCP window scaling can actually help; otherwise you will see flat throughput well below link capacity even when ping looks acceptable. Tuning belongs primarily on long-lived Linux relays or registries you control—not on every laptop—and always behind change control.

# ── Linux relay / bastion you control (NOT random macOS clients) ──
# Boundary: apply only on dedicated transfer hosts; measure before/after;
# revert if middleboxes or legacy firewalls mishandle large windows.
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.core.rmem_max=134217728 net.core.wmem_max=134217728
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 67108864" net.ipv4.tcp_wmem="4096 65536 67108864"

# OpenSSH client for bulk (per-job or ~/.ssh/config stanza)
# Boundary: Compression=yes can hurt on already-compressed artifacts.
scp -o Compression=no -c aes128-gcm@openssh.com -o IPQoS=throughput …

# OpenSSH server snippet (sshd_config) — boundary: tune MaxStartups with load test
# MaxStartups 10:30:100
# ClientAliveInterval 30

Summary — buying and provisioning: pick the vpshalo PoP that matches both your SSH control plane and your artifact lane before you sign a quarter’s worth of builds on the wrong coast. Confirm p95 on a reference object, lock checksum policy, wire retry budgets, then purchase or extend Mac capacity in that same region so finance, DNS, and bytes-on-the-wire tell one story. Re-run the matrix after every major DNS or registry move.