DONE SIGCOMM 2026のaccepted paperのアブストを全部読んで気になったやつまとめ

-

What is this?

SIGCOMM 2026が開催されていたので、accepted paperのabstructを全部読んで興味があるやつを探して行く。

この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 latecyの事前予測を行う。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などHCPの分野で利用されている、パケットスプレーなどでは同じ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やAL/MLなどのワークロードがGoogleのDC内に構築されてそれにより、厳密な可用性が求められ、また想定しない速度でのWANの増強が求められている。
  • これらの課題に対応するために設計したGoogleの新しいWANのアーキテクチャ再設計であるGoogle Global Network(GGN)の紹介
  • GGNの複数年に渡る導入実績を紹介する
  • Plant 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のSDNのポリシーエンジンの提案
  • 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

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をアクセラレーションする方法は学術的によく研究されている
  • しかし、実環境に導入した例は少ない
  • Aliava 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