DONE SIGCOMM 2026のaccepted paperのアブストを全部読んで気になったやつまとめ
What is this?
SIGCOMM 2026が開催されていたので、accepted paperのabstractを全部読んで興味があるやつを探して行く。
このBlogの著者の属性
- インフラソフトウェアのエンジニア(最近はManager roleが多め)
- Private Cloudエンジニア
- NW機器ではなくソフトウェアの面倒をみている
- DNS/LB/Service Meshを仕事で開発している
- 論文の調査は本業ではなく、趣味
2026-08-23 11:44 - Critical Path Guided Decision Making with CALLIGATOR
Critical Path Guided Decision Making with CALLIGATOR
- Calligatorというマイクロサービス分析フレームワークの提案。
- Traceを元に依存関係分析を行い、クリティカルパスの判定を行う
- まあ、その依存関係を元に、P99などのボトルネック分析が可能になり、Tail latencyの事前予測を行う。Tail Latencyの分析性能は81.7%になり、既存の物よりも高い値になっている。
Tracingから依存関係の分析に必要な情報などを知りたい。 Tail Latencyはナイーブな物と比べてリサーチ分野ではどのようなアルゴリズムがあるのか知りたい。
#ServiceMesh
2026-08-23 12:31 - Honey, I Shrunk the Headers With Flow.ZIP
Honey, I Shrunk the Headers With Flow.ZIP
- overlay networkにおけるヘッダーのオーバーヘッドを圧縮するFlow.ZIPの提案
- 既存のOverlayによるカプセル化をMPLS Layerに変換する形で汎用的なNetwork機器に対応するらしい
圧縮する方法と、だったら、最初からMPLS話せば良いんじゃないか?という気持ちをどう解決してくれるのか気になる。
#VPC
2026-08-23 12:38 - OmniPath Ping: Active Network Measurement in the Era of Packet Spraying
OmniPath Ping: Active Network Measurement in the Era of Packet Spraying
- PingやtracerouteはNWの障害の調査によく利用される。
- Clos環境などのECMP環境下ではsrc portを変更するなどして複数のPathを通して分析するToolなどが存在し利用されている
- しかし近年、GPU ClusterなどHPCの分野で利用されている、パケットスプレーなどでは同じFlowでも分割されてしまう
- この論文では、パケットスプレー環境下にも対応したOmniPath Pingを提案する。
- OmniPath Pingでは、以下の提案をしている
- パスの曖昧さを解消するためにホップごとのテレメトリをキャプチャするネットワーク内OmniPathキャッシュ、(2) 冗長性をゼロにして完全なパスカバレッジを可能にするネットワーク内重複および重複排除メカニズム。ネットワーク全体のサービス追跡のスケーラビリティをさらに確保するために、OPPは(3) OmniPathキャッシュSRAMの使用とプローブの適時性のバランスを取るトポロジ認識型並行性制御メカニズム
NWの複雑性が増えると、調査方法も複雑になるので、まず、どのような方法が使えるのか知りたい。 このまま実装はおそらく不可能だが、コンパクトな方法を考える足掛かりにしたい。
#o11y
2026-08-23 12:45 - Comprehensive Revocation Checking at Scale: the Deployment of CRLite in Mozilla Firefox
Comprehensive Revocation Checking at Scale: the Deployment of CRLite in Mozilla Firefox
- MozillaがCRLiteをブラウザに組込むために行なった取り組みの紹介
- CRLiteは確率的データ構造を採用している
- CRLiteは生成されたデータを適切に同期を実施する必要がある
- 2025年11月のMSの事件のような実際の証明書の無効に対応した
- CRLiteを用いて低遅延で包括的な証明書チェックが可能である事を示した。
ただただ、インターネット野次馬なので読む。 証明書の失効管理がそもそも難易度とコストが高い世界になっているし、証明書の日数が短くなるし、もう、失効管理はなくても良いのでは?みたいな気持ちはやっぱりある。
#TLS #Browser
2026-08-23 12:55 - PacketExpress: Fully Exploiting Large MTUs for Internet Traffic in Private Networks
PacketExpress: Fully Exploiting Large MTUs for Internet Traffic in Private Networks
- インターネットのパケットのMTUは多くの環境で1500バイトに制約されている
- しかし、DC内NWなどでは9000バイトなどの大きなパケットでの転送が可能になっている
- この1500バイトという小さなMTUは処理するべきパケット数を増加させNW機器の負荷になっている
- この研究ではMTU変換GatewayであるPacketExpressを紹介する
- PacketExpressは受信した小さなパケットを集約して大きなパケットに効率的に集約して処理します
- また、この実装に利用したNICのオフロード機能を活用して高いスループットを実現するパケット処理スタックであるPXIOの紹介をします。
- またICMPを利用せずにPath MTU discoveryを実施するF-PMTUDを紹介します。
MTUのサイズ問題はあるが、Gatewayで解決するというのは力技ですごい。 技術力で有無を言わせず解決している感じが、KAISTみがあるので面白そう。
#DCN #Internet
2026-08-23 12:59 - GGN: Experiences in Designing and Deploying the Next-Generation Google Global Network
GGN: Experiences in Designing and Deploying the Next-Generation Google Global Network
- 近年、CloudやAI/MLなどのワークロードがGoogleのDC内に構築されてそれにより、厳密な可用性が求められ、また想定しない速度でのWANの増強が求められている。
- これらの課題に対応するために設計したGoogleの新しいWANのアーキテクチャ再設計であるGoogle Global Network(GGN)の紹介
- GGNの複数年に渡る導入実績を紹介する
- Planet Scaleでの最新のWAN基盤を構築する
インターネット野次馬なのでハイパースケーラのインフラ論文はとりあえず読む。 クラウドが入った事によって、可用性の測定などが厳密に必要になっている事を感じるので、そのあたりにどのように対応しているのか知れれば良い。
#DCN
2026-08-23 13:04 - Understanding Host Network Stack Latency
Understanding Host Network Stack Latency
- Linuxのnetwork stackは遅延が大きい事で知られており、そのためDPDKやXDPといったネットワークスタックをバイパスする方法がとられる事が多い
- しかし、一般的な問題として解決するにはLinuxのNetwork Stackの改善を行わなければ幾度もこのバイパスによる改善が繰り返される事になる
- そこで、LinuxのNetwork StackにおけるTail Latencyの根本的な原因の調査を行なった
- 調査の結果、主なボトルネックはパケット処理ではなくCPUリソースの管理方法にある事を発見した。
- これらの問題に対してスケジューラの観点から対処する事で、スループットを維持しながらLatencyを、5.3倍向上させる事が出来る事を示した
普通のLinuxでもまだまだTuning出来る範囲があるというのが面白い。 この分析結果自体よりも、どのようにそれを分析すれば良いのかという手法を知りたい。
#Linux
2026-08-23 13:09 - Rules Offload Engine (ROE): Accelerating Host SDN Policy Evaluation
Rules Offload Engine (ROE): Accelerating Host SDN Policy Evaluation
- FPGA SmartNICをベースとしたSDN Ruleのポリシーエンジンの提案
- FPGAをベースとして、評価を高速に処理するためのハードウェアとソフトウェアの設計であるRules Offload Engine (ROE)の紹介をする
- SDNのポリシーに特化した、ROE Instruction Set Architecture (RISA)を提案します
- ROEはAzureにデプロイ済で運用されている。
Azureのnetwork stackのFPGA化がちゃくちゃくと進んでいて、パケット転送などはこれまで実施していたが、今回、Ruleの評価までFPGA化したので、いよいよ、HV内で処理している物がなくなってきたのではないかと思う。 発展を読んできているので今回の進化も楽しみ。
#Cloud #SDN
2026-08-23 13:13 - Gryphon: Scaling Hyperscale Multi-Tenant Gateways Beyond the Petabit-Era via DPU-Augmented Hierarchical Co-Offloading
- ByteDanceで運用しているクラウドゲートウェイのGryphonの紹介
- 従来のASICのみのゲートウェイではオンチップのリソース制約が厳しく柔軟性に欠けていた
- スイッチングASICの転送パスにDPUを直接統合したハイブリッドアーキテクチャに基づいたハイパースケールクラウドゲートウェイとして構築している
- テーブル規模を最大1000倍に拡張し、プログラマビリティを強化しながら、平均レイテンシを約8μs増加させるだけで1.6Tbpsのラインレートスループットを提供している
- コントロールプレーンでは、ハードウェアの詳細とポリシー構成を分離する抽象化レイヤー（P4Bridge）を開発した
Gatewayの帯域問題は気になるので読む。 どのようなRuleを処理したいのかも気になるのでそのあたりが読めれば良い。
#Cloud
2026-08-23 13:21 - HERMES: Repurposing User-Driven Speed Tests to Monitor the Internet
HERMES: Repurposing User-Driven Speed Tests to Monitor the Internet
- 公開されているM-LabのSpeed testのデータを利用したEnd Userのパフォーマンス低下の観測手法を提案する
- 既存のソリューションでは粒度があらく実際のユーザのパフォーマンス低下といえる状態ではなかった
- このシステムでは、オープンなデータを利用しながら、大規模なCloud Providerのシステムと94.5%でパスの性能低下の原因などについて合致するものを構築出来た。
- パフォーマンス低下を検出するための統計的手法と、問題の原因を特定するための新しいトモグラフィー手法および順方向と逆方向のパス測定を組み合わせています
Speed Testのデータという継続的な物ではない情報からどのような統計的な手法を利用して分析しているのか気になるし面白そう。
#o11y
2026-08-23 13:26 - Detection and Localization of End-to-end Bitflip Errors in Data Centers
Detection and Localization of End-to-end Bitflip Errors in Data Centers
- パケット破損やビット反転などがNW内で発生する事は稀だがハイパースケール環境では頻発する
- 実際にMetaではサービスのパフォーマンス低下が数十件、まれにデータの破損まで発生している
- このNW機器でのパケット破損デバイスを検知するためのシステムの構築を行なった
正直、活用出来る事はなさそうだが、どのように問題点を特定していくのかというソフトウェアの設計が気になる。
#o11y
2026-08-23 13:31 - When static verification is not enough: revealing BGP bugs at runtime
When static verification is not enough: revealing BGP bugs at runtime
- 動作しているBGPルータを監視しプロトコル仕様への準拠を検証するGhostBusterの紹介
- GhostBusterは観測されたBGPの送信メッセージが受信メッセージによって生成されうるか検証を行う
- BGPのメッセージは受信された物からシリアルに出されるとは限らないので、あらゆる順序関係に対処する必要があるが、順序に関係なくBGPの入出力セットとしてとりあつかう事で対処した
- GhostBusterは実際に動作しておりバグを検出し、また誤ったバグ報告は1度もない
BGPは結構多様性があるので、動いているのが正義な所もあるが、それはそうとして運用として事故るのでこのあたりがちゃんと検証や怪しい挙動として検知出来るのであれば良さそう。 BGPのパケットキャプチャだけであればそれなりに導入も出来そう。
#BGP
2026-08-23 13:47 - Rethinking Cloud Optimization: Volatility-Driven for Better Outcomes
Rethinking Cloud Optimization: Volatility-Driven for Better Outcomes
- クラウドプロバイダーは収益性を最大化するために、オーバーサブスクリプション戦略を一般的に採用しています
- ワークロードの時間的変動性により、オーバーサブスクリプションされたノードに過負荷が発生する可能性があります
- それに対応するために過負荷イベントによってリソースの再スケジュール戦略がとられている
- しかし、既存のアプローチでは、テナントのエクスペリエンスかプロバイダーの収益の何れかを低下させる事が分かっている
- この論文では、相互補完的なワークロードを集約することで時間的変動性を低減できることを示しています。この洞察に基づいて、ワークロードの時間的変動性を定量化するために、まず最大値ベースの変動係数（MCV）と呼ばれる新しいメトリックを設計し、安定したオーバーサブスクリプションを実現するためのHestiaというフレームワークを提案します。
Private Cloudとして集約効率を上げるのはPublic Cloudよりも求められているので、このあたりはめちゃくちゃ気になる。 一般的にメトリクスとして利用出来るのであれば、実装を検討したい。
2026-08-23 13:59 - Horizon: A Hyper-Edge Observability Engine for Live Streaming Networks
Horizon: A Hyper-Edge Observability Engine for Live Streaming Networks
- ライブストリーミングサービスを大規模に安定稼働させることは困難で、障害はユーザー側の配信パスやストリーミングプロトコル、アプリケーションロジック内で発生するため、オペレーターは、インシデントを迅速に検出して特定するための継続的なランタイム監視と、代表的な環境下での変更と持続的な再生動作の検証の両方を必要とします。
- この論文ではByteDanceのISPにホストされるEdge Deviceを利用してユーザに近い場所から常時監視とカスタマイズ可能なシナリオ駆動検証をサポートするHorizonを紹介する
ByteDanceのHyperEdgeが最近面白いので読みたい。 ByteDanceのHyperEdgeはCDNなのだがユーザの端末で動くアプリなどと密に連携して動く構成なのでユーザとの関係が他のCDNと違うので読んで面白いはず。
#o11y
2026-08-23 14:07 - Achieving Network Efficiency Through Service Collaborative Capacity Sharing and Enforcement
Achieving Network Efficiency Through Service Collaborative Capacity Sharing and Enforcement
- 物理的な制約が、容量増加の速度を制限しています
- これらの課題に対処するため、サービス連携アプローチによってネットワーク効率を体系的に向上させる、サービス認識型ネットワーク容量計画スイートを提案する
- サービス連携アプローチによって、ネットワーク効率を体系的に向上させる
- サービスが現在のネットワーク状況と予測されるネットワーク状況を、コンピューティングとストレージの割り当て決定に組み込めるようにする「安全容量」抽象化を提案します
- さらに、エンドホスト層における制限により、実行時にリソース割り当てとトラフィックフローを動的に調整し、利用率を最大化します
Endを持った上でそのNWに乗るサービスと連携したDCNWを設計することでネットワーク効率化を行うというのは、自分が結構やりたい事でもあるので、面白そう。 どのようなデータから決定的に必要な容量の推定などが出来るのかを知りたい。
#DCN
2026-08-23 14:15 - Don’t Stall Me Now: Hiding Memory Latency in eBPF
Don’t Stall Me Now: Hiding Memory Latency in eBPF
- eBPFは、高性能I/Oプログラムを構築するために多く利用されている
- しかし、eBPF MAPの制限などにより利用出来るData構造が制限され、Cache missなどに対処する事が難しい。
- Cache missに対応するためのデータ構造などを自分で実装することも難しい
- これらの問題に対処するBeeswaxというアプローチの提案
- このアプローチでは、プログラマブルなマルチフェーズデータ構造を採用し、プログラムを複数のステージに分割します
- そして、プログラムの実行をオーバーラップさせることで、キャッシュミスによるオーバーヘッドを隠蔽する
- Katranによる実験で最大99%のスループットの向上を確認した
いよいよ、XDPではなくなってきそうな感じになっているが、XDPの処理をもっとパイプライン化したい、みたいな気持ちは分かるので、楽しく読めそう。
#LoadBalancer #eBPF
2026-08-23 14:27 - A Global Inference and Assessment of Large Shared IP Addresses
A Global Inference and Assessment of Large Shared IP Addresses
- NAT、VPN, Proxyなどにより1つのPublic IPを多くのクライアントで共有する、という構成が一般的に存在する
- しかし、観測の制限やインターネット上でのデータの欠如により、Multi User IP(M-IP)とそのサービス提供への影響を明確に区別する事は難しい
- グローバルCDNリクエストログから抽出した特徴量を用いて、公開ソースのデータに注釈を付けることで分類器をトレーニングしM-IPを検出するための推論手法を考案する
現在のIPアドレスの共用とその分析方法に興味がある。 DNSやProxyを運用しているとそれが集約された時の影響を知りたい事がままある。 M-Labのデータを利用してモデルの構築も出来るようなので、それをAdapt出来るのか考えたい。
#CDN #o11y
2026-08-23 14:29 - Rethinking Transparent TCP Replacement: Practical Lessons from SMC-R in the Cloud
Rethinking Transparent TCP Replacement: Practical Lessons from SMC-R in the Cloud
- 透過的にTCPをアクセラレーションする方法は学術的によく研究されている
- しかし、実環境に導入した例は少ない
- Alibaba Cloudに過去4年、透過TCPアクセラレーターのSMC-Rを導入した経験を報告する
TCPアクセラレータ系はProxyのLatency系でちょこちょこ論文を観ていたが、それを実際に導入して問題だった所が分かると、自分の検討の幅も広がるので読みたい。
#Proxy #TCP
2026-08-23 14:32 - Planogram: A Multi-dimensional Physical Location Planning System for DC Networks
Planogram: A Multi-dimensional Physical Location Planning System for DC Networks
- Metaで運用しているDCNの物理的な位置をMappingするフレームワークであるPlanogramの紹介
- Planogramは論理ネットワークと物理ネットワークを物理的なデータセンターのフロアプランに対応付ける
あるサービスが実際に何処で動いているのかを知るのは結構難しいので、気になる。 Applicationのネットワークの遅延なんかの分析やコスト最適化まで幅広く使いたい。 どんな感じの設計で作って、どのくらいの遅延があるのかなんか知れると良い。
#DCN
2026-08-23 14:36 - Capybara: Dynamic Load Balancing with Microsecond-Scale TCP Migration
Capybara: Dynamic Load Balancing with Microsecond-Scale TCP Migration
- L4LBはTCPレベルで高速にバランシングするのでTail latencyなどに対して一般的な解決策になっている
- しかし、偏ったトラフィックなどの環境ではバックエンドもかたよる事になりパフォーマンスが低下する
- そこで、connectedな接続を動的にリバランスする新しいL4LBのアーキテクチャであるCapybaraの提案を行う
- Capybaraはプログラマブルスイッチとカーネルバイパスを活用してクライアントに対して透過的に、バックエンドのマイグレーションを実施する
透過的にリバランスする系のLBは定期的にあるがこれまではバックエンドのプロセスMigrationに近い形だったけど、カーネルバイパス系で対応するらしい。 処理の内容とかどうするのか気になる。 これをするぐらいなら普通にサービス側になんとかしてもらった方が良いが、存在を知っておくには良い。
#LoadBalancer
2026-08-23 14:41 - From Nimitz to NetPila: The Evolution of Production-Scale Container Network
From Nimitz to NetPila: The Evolution of Production-Scale Container Network
- Alibaba Cloudの第二世代のCNIのNetPilaについての紹介
- 第一世代はVXLANを利用していたが、C100K問題に直面した
- この問題に対処するため、シンプルなIPv6を利用し、VXLANやオーバーレイ、アンダーレイマッピングテーブルを排除した
- NetPilaはコンテナのアドレスをIPv6アドレスに埋め込む事でステートレスに動作する
- NetPilaは現在数百万個のコンテナをサポートしています
IPv6にアドレスを埋め込むというのが個人的に好き。 普通にIPv6でVMに /64とかで割りふっとけばこういう事も簡単に出来るようになるよなーとは良く考える。 実際に導入した物の設計などを知りたい。
#CNI #k8s
2026-08-23 14:44 - CacheFlare: Optimizing Cold Content Performance in CDNs
CacheFlare: Optimizing Cold Content Performance in CDNs
- CDNに関する既存の研究は、主にホットコンテンツの最適化に焦点を当てています
- しかし、Metaでは、アクセス頻度の低いコールドコンテンツが、大量のダイレクトメッセージングメディアにおいて、ユーザーエクスペリエンスに大きな課題をもたらすことを発見しました
- MetaのCDNデータを詳細に分析することで、コールドコンテンツのパフォーマンスがユーザーエクスペリエンスに与える影響を定量化し、地域によって大きな違いがあることを明らかにしました
- これらの知見によって設計されたCacheFlareを提案する
コールドコンテンツが多い物のHit Rateを上げたいのは凄い分かるが、だとしてもCDNとの相性がそんなに良くない。 それをどのように解決しているのか気になる。
#CDN