A 3-month E21 (Ethiopia) investigation into unreliable YouTube blocking found two independent, structural detection gaps: (1) at IGW (international gateway) sites, load-balanced multi-path routing causes TSG to see only single-direction (C2S-only or S2C-only) traffic for a meaningful fraction of sessions (~5-10% baseline, worse under load), breaking stateful app-ID/deny; (2) under peak load, NPB boards' CPU-triggered self-protection "bypass" (fail-open passthrough) hit ~50% of new sessions at the busiest site (Bole-IGW, ~86k new sessions/sec at 7.8Gbps/NPB), and TSG explicitly deprioritizes bypass protection for non-HTTP/SSL traffic to preserve web blocking under load.
Bole峰值流量下（晚上21:30），TCP新建每秒已经超过6w CPS，此时功能端bypass比例接近50%...升级sapp，Bypass时，跳过常用端口（如443、80），从而一定程度上，优先保证Deny效果
Defense implications
- At gateway nodes with asymmetric/multi-path routing, a real baseline miss rate exists independent of any client-side defense — worth confirming whether this generalizes beyond Ethiopia's topology.
- Traffic concentrated during a node's known peak-load window has a measurably higher chance of passing unfiltered via fail-open bypass; this is an operational/timing consideration, not a protocol design one, and is speculative until corroborated elsewhere.
- TSG prioritizes maintaining HTTP/SSL (443/80) enforcement specifically under load — non-standard ports may see relatively better pass-through during congestion, though this needs more evidence before treating as reliable.
Related findings
TSG's QUIC-parsing layer decrypts QUIC ClientHello payloads and parses a user-agent-like parameter from the decrypted content, deployed at the Ethiopia (E21) DIR-IGW site. A missing bounds check on this field caused a watchdog-timeout crash, confirmed via a MESA_Platform/quic GitLab commit (git.mesalab.cn/MESA_Platform/quic).
A debugging ticket for sites "Old Airport-PE" and "Bole-IGW" (naming consistent with Addis Ababa, Ethiopia) confirms the customer verified Psiphon3, YouTube, Facebook, and Telegram blocking as working well during independent testing, and reveals the operational session-correlation method used when packet captures and system logs must be cross-referenced across NAT: JA3_HASH + server IP + client public IP + SSL SNI.
A MESA Lab task tracker records the assignment "TSG: determine how many clients are behind an IP address," and a companion technical design document details the method: identify distinct TLS clients sharing one public IP using a <JA3 fingerprint, server domain, server IP> 3-tuple (JA3 alone collides across different apps), then use TLS Session Ticket reuse/lifetime sequences per identified client to detect multiple concurrent devices (i.e. NAT) behind that IP.
Side-by-side internal performance comparison across Xinjiang (China Mobile carrier deployment, hostname cmcc-xj-server1-sapp-244), Fujian (domestic), and Ethiopia (E21) explicitly references the same 'app_sketch_maat' diagnostic log format at all three sites, confirming the identical AppSketch app-fingerprinting stack is used for domestic Xinjiang surveillance and for the exported Ethiopia deployment.
Direct dated evidence (July 2023) that the Ethiopia (E21) customer actively toggles application-level blocking as a live policy lever: lifting the block on YouTube plus four other apps caused a documented traffic surge and device alerts at the BOL-IGW site.
Raw TSG session_record export logs dated Nov 2024, tagged device_group 'YGN-MYTEL' (Yangon, Mytel), directly corroborate the leak's M22=Myanmar/Mytel/Yangon site-codename mapping with live production data: individual SSL sessions are classified by app as 'Hotspot Shield VPN' (destination get.adobe.com, likely a fronting/CDN endpoint) and allowed under a named whitelist rule 'whitelist_102024', geolocated client-side as Myanmar.Yangon.Yangon.