Multipath Transport Protocolを用いたSRv6 BGP Egress Peer Engineeringによる高品質・高信頼なコンテンツ配信
Perfomance Aware Content Delivery Using Multipath Transport Protocol with SRv6 BGP Egress Peer Engineering
1. はじめに
インターネットを介しコンテンツを提供する事業者（Content Service Provider: CSP）のサービスにおいては，ネットワークの通信品質（Quality of Service: QoS）がユーザの満足度に大きく影響することが知られている[1]．多くのCSPは，冗長性や収容容量の拡大を目的として複数のトランジット事業者やInternet Exchange（IX）と接続し，複数の対外接続経路（Egress Path）を持つ．たとえばFacebookの自律システム（Autonomous System: AS）は，クライアントに対して平均3つのEgress Pathを有すると報告されている[2]．CSPはこれらの経路からBorder Gateway Protocol（BGP） [3]のベストパス選択ルールにより1つのEgress Pathを利用し，コンテンツを配送する．
BGPベストパスは必ずしも通信品質に即して選択されるわけではなく，しばしばコンテンツ配信のパフォーマンス劣化を引き起こすことが知られている[4], [5]．下記の主な3つの原因から，BGPによって品質に基づいた経路選択を行うことは困難である．
- (1) BGPは直接的に品質を示す経路のパラメータを持たない
現行のBGP経路決定メカニズムは，経由するASの数を表すAS_PATH属性や，運用者が適宜行う重み付け（BGPポリシー）に依存しているため，直接的にEgress Pathのパフォーマンスに基づいた経路選択ができない．QoSメトリクスを用いた経路交換の試みとして，BGPの拡張属性[6]や独自のSoftware Defined Network（SDN）機構を利用したもの[7]が提案されている．しかし，これらの手法は多くのASで広く導入されるまでメリットを受けにくい課題があるほか，ASの競争力に関わるネットワーク内部の品質情報を他のASに公開する必要があるため，現在に至るまでインターネット全体で広く利用されているものは存在しない． - (2) Egress Pathの性能評価と選択ポリシーの随時適用が困難
顧客までの通信経路上には，CSPの管理下に無いいくつもの事業者のASのネットワークが存在する．そのため実際にトラフィックを流して計測しなければ，経路品質を評価することはできない．仮に通信品質が良い経路を発見できたとしても，通信品質は流動的であり，トラブルの原因となり得る品質低下は常に観測可能とは限らないため，解決がより困難になっている．実際に，コンテンツサービスの配送品質に関する問題が発生した場合の原因調査と特別なBGPポリシーの管理には，多くの労力と時間が必要となる[8]． - (3) コンテンツによって要求品質が異なる
コンテンツ利用者が体感する品質（Quality of Experience: QoE）は，本質的に定量化が困難な概念である．しかし，測定可能なQoSメトリクスが顧客のQoEに及ぼす影響を定量的に評価するため，一定の仮定のもとにQoE値を推定する取り組みが様々な領域で行われている[9]．当然ながら，コンテンツの種別によって推定QoE値を適切に導出するためのモデル[10]）は異なる．そのため，AS全体で宛先ネットワークごとに原則として1つのパスを選択する（BGPベストパスのみを利用する）場合，いくつかのコンテンツサービスでは最適なEgress Pathを利用できないことになる．
つまり，CSPが多様な隣接ASと接続し，利用できるEgress Pathの数を増加させたとしても，常にユーザやプロバイダが希望するパフォーマンスを得られるかどうかは未知数である．
BGPのベストパス選択ルールによらずEgress Pathを選択し，アウトバウンドトラフィックを制御する技術はEgress Peer Engineering（EPE）と呼ばれる[11]．EPEを用いた経路選択により，コンテンツ配信品質の向上が見込めることが，プロダクション環境を利用した実証実験から明らかになっている[12]．以降本稿では，エンドツーエンド（E2E）でのパフォーマンス向上を目的としたEPEを特に“Performance Aware EPE”と呼称する．
高品質なBGPパスを利用して継続的にサービスを提供するためには，利用可能なEgress Pathを適切に管理し，コンテンツサービスに最適なものを選択・利用する必要がある．本研究では，Performance Aware EPEの実現のために求められる役割と機能を整理し，SRv6 L3VPNとMultipath TCP（MPTCP）を活用したEPE用のコントロールプレーンスタック“Multipath Transport SRv6-EPE Suite”を提案する．このコントロールプレーンは，他のASに協力を仰ぐことなくコンテンツ配信品質の向上を見込める点や，通信品質やBGP経路の変化に動的に追従できる点，そして，多様なコンテンツサービスに適合する柔軟性がある点で特徴的である．
はじめに，インターネットコンテンツ配信環境を模した仮想環境での実験を通じて，Multipath Transport SRv6-EPE Suiteの有用性を評価した．すべてのテストケースにおいて，本提案手法は従来のBGPベストパスのみを利用したコンテンツ配信と同等以上の性能を有したほか，いくつかのケースにおいては配信品質を大きく向上できることを明らかにした．また，ネットワーク環境の変化を想定した2つのテストケースにおいても，本提案手法は通信経路上の品質劣化のコンテンツ提供品質に対する影響を大きく低減できることが分かったほか，BGP経路の変更にも迅速に対応可能なことを示した．
次に，実際のインターネットAS上で動作するコンテンツサーバにMultipath Transport SRv6-EPE Suiteを実装し，日本の主要な4社のモバイルISPを含む9つのISPに接続するサンプルクライアントに対して，実際にコンテンツサービスを提供する評価実験を行った．この評価実験では，BGPベストパスのみを利用した従来の配信環境と比較して，9つ中6つのISPで10%以上スループットが向上し，うち4つのISPでは50%以上の顕著なスループット向上を確認できた．
本稿の貢献は以下のとおりである．
- ・EPEコントロールプレーン：ネットワークの状況に応じて動的にトラフィックを制御する（Performance Aware EPE）ために必要な機構の設計
- ・“Multipath Transport SRv6-EPE Suite”の提案
- ・実際のコンテンツ配信環境での有用性の評価と，今後の技術課題の整理
2. 要件定義
2.1 想定するネットワーク
本研究が前提とする，CSP ASがIPv6インターネットを介して様々なコンテンツ配信を行うネットワークの概略図を図1に示す．CSPは自社のネットワークをASとして運用し，内部にはコンテンツサーバや外部接続を担うルーター（Autonomous System Boundary Router: ASBR）などが存在する．CSPはTransit AS，Public Peer，Private Network Interconnect（PNI）など，複数の外部接続点（Egress Peer）を持ち，BGPベストパス選択ルールに基づき，宛先ネットワークごとに一意のEgress Pathを選択する．図1の例では，3つのEgress Pathの中からEgress Path αを選択して利用している．
Fig. 1 Network between the Content Service Provider (CSP) and content clients.
また，CSPは多様なコンテンツを提供する故にそれぞれスループットや遅延，パケットロスなどのQoSに対して異なる要求基準を持つ．しかし，通信経路上にはCSPの管理下に無いネットワークも存在するため，コンテンツの提供に際し，これらの基準を事前に満たすことは困難である．
CSPは複数のデータセンターにまたがり構成される場合もあるが，全拠点を同一のポリシーで運用する際はルーティング上の差異が存在しないため，本稿では考慮しない．
2.2 SRv6-EPE
Segment Routing（SR）は，ソースルーティングに基づくトラフィックエンジニアリングの実現手法である[13]．パケットの転送対象をSegmentと呼ばれる単位で扱い，SR Header（SRH）に埋め込んだSegment Listを用いて，パケットに与える転送処理を制御する．SR技術のうち，IPv6拡張ヘッダを利用するものにSRv6 [14]がある．
SRv6のセマンティクスでは，IPv6アドレス形式で記述するSegment Identifier（SID）と呼ばれる識別子を用いてSegmentを表現する．SIDは，そのパケットを経由させるノードを表す“Locator”と，そのノードで行う処理（SRv6 Behavior）について記述する領域によって構成される．SRv6はこのSIDの表現性を利用して様々なネットワークサービスを活用できる．
本研究ではSegment RoutingによるEPE運用モデル[11]のうち，SRv6の仕組みを利用したEPE実現手法を“SRv6-EPE”と呼称する．SRv6-EPEは，ASBRがパケットをEgress PeerごとにユニークなSID（以後“SRv6-EPE SID”と呼ぶ）で識別し，送信元ホストがSRv6-EPE SIDを付与することで，BGPベストパスによらずにパケットを転送できる．この仕組みにより，アプリケーションレベルでのEgress Path選択が可能となり，既存のBGPベストパス選択の制限を超えた自由なトラフィック配送が実現される．
SRv6-EPEは他のEPE実現手法と比較して，（1）中継ネットワークに非依存である点，（2）EPEを利用しないトラフィックと共存できる点，（3）既存のIPルーティングの技術を活用できる点で優れているため[12]，本研究ではSRv6-EPEによりEPEを実現する環境を想定する．
2.3 Performance Aware EPE
本研究では，BGPベストパスにかかわらずパフォーマンスに基づいてEgress Pathを選択し，通信品質向上を目指す取り組みを“Performance Aware EPE”と呼ぶ．第1章で述べたように，オペレータがコンテンツに適したEgress Pathを手動で選択し，随時これをサービスに適用するのは困難である．そのため，Performance Aware EPEを実現するためには，ネットワーク状況の変化に応じて動的にトラフィックを制御する機構が必要になる．この機構には下記の2点の働きが求められる．
- (1) CSP ASが利用可能なEgress Pathの把握と共有
- (2) Egress Pathのパフォーマンス評価とポリシーの随時適用
（1）の実現にはSRv6-EPEを適切に動作させるネットワーク環境の整備が，（2）の実現にはコンテンツの配信品質を最大化するEgress Pathの選択と利用を行う仕組みがそれぞれ求められる．本稿ではこれらを兼ね備えた制御機構を「EPEコントロールプレーン」と定義し，必要となる機能を分類して整理する．
2.4 EPEコントロールプレーンに求められる要求事項
第2.1節で定義されたCSPのサービスでは，変動するネットワーク環境上でコンテンツごとに異なる品質要件を満たす必要があるため，EPEコントロールプレーンには以下の要件が求められる．
- (1) コンテンツ配信品質の向上
Performance Aware EPEは，通信品質が優れたEgress Pathを適切に選択し，配信品質を向上させることを目的とする．実世界ではCSPの管理外のASが経路上に存在するため，実際にトラフィックを送出することによるEnd-to-Endでのパフォーマンス測定と評価が必要である．適切にEgress Pathを評価するためには，実際に利用者に提供されるコンテンツの通信品質を指標とするのが望ましい[12]． - (2) 通信環境の変化への追従性
第1章で述べたように，インターネットの通信品質や到達性は日常的に変動するため，EPEコントロールプレーンは，これらの変化に対応し，コンテンツサービスの中断や品質悪化を防ぐ必要がある． - (3) 多様なコンテンツへの柔軟性
第1章でも述べたように，コンテンツサービスの種類や特徴によって求められる品質基準は異なる．EPEコントロールプレーンには，これら多様なQoS品質要件に対応する柔軟性が求められる． - (4) 展開の容易性
第1章で触れたように，現状のBGPには直接的に品質を示すパラメータがなく，品質情報をAS間で交換するための機能拡張も，多くのASに導入されるまではメリットを享受することが難しい．EPEコントロールプレーンは，隣接する協力無しにCSP ASに展開可能なことが求められる．また，新規機能を既存サービスに追加する際には，サービスの継続性を維持することが課題となる[15]．CSPがEPEコントロールプレーンを導入する際には，既存のネットワークやサービスへの影響を最小限に抑えつつ，ビジネスの継続性を保つことが必要である．さらに，展開に必要な新たな機構を最小限に抑えることは，運用に掛かる負荷の軽減につながる．
3. EPEコントロールプレーン
本章では，EPEコントロールプレーンに必要となる機能群を定義し，それぞれの目的と担う役割について述べる．
図2はEPEコントロールプレーンの各機能およびデータプレーンとの相互関係を示したものである．EPEコントロールプレーンには，その性質から“EPE Provisioning and Reachability Management”と“Quality-Based Egress Path Decision Making and Traffic Control”の2つの役割が存在する．
Fig. 2 Components and interactions in the EPE control plane.
3.1 EPE Provisioning and Reachability Management
第2.4節で述べた「SRv6-EPEを適切に動作させるネットワーク環境の整備」を担う役割を，本研究では“EPE Provisioning and Reachability Management”と定義する．これは下記の機能から構成される．
- ・SRv6 Locatorの発行と到達性の管理
SRv6 SIDはLocatorとFunctionおよびArgumentで構成される[14]．SRv6-EPEにおいてLocatorはASBRごとにユニークに割り当てられるprefixであり，CSPネットワーク全体からのIPv6到達性が必要となる．これはネットワーク内ですでに運用されているInterior Gateway Protocol（IGP）の経路制御機構によって実現される． - ・SRv6-EPE SIDの発行・削除
ASBRは自身のLocatorと各Egress Peerごとにユニークな識別子を組み合わせてSRv6-EPE SIDを生成し，そのSIDが付与されたパケットをSRv6ヘッダを除去したうえで，対応するEgress Peerに転送するために必要なルールをルーティングテーブルに設定する．Egress Peerとの接続やBGP隣接関係が失われた際にルールを削除し，不要なトラフィックの送出を防ぐ機能も必要となる． - ・経路とSRv6-EPE SIDの紐づけと広告
CSPのEgress Peerにはインターネット全体への疎通性を提供するトランジット事業者のほかに，自身の顧客の経路のみを広告するISP事業者や，一部の地域の経路のみを提供する“Partial Transit”事業者[16]が存在しうる．そのため，すべてのEgress Peerから等しく任意の宛先に到達可能であるとは限らない．Egress Peerから広告されていない経路宛の通信をそのEgress Peerに送出する行為は，その通信が宛先まで到達しない可能性があるのみならず，Egress Peerのネットワーク容量を窃取する不当な行為と見なされる可能性がある[17]．実際に中村らが2021年に行った調査[18]では，多くのASがこのような行為に無防備であったことが報告されている．BGPの経路選択によらずにトラフィックを制御するEPEを運用する場合，意図的なものであれ偶発的なものであれ，Egress Pathの適切な利用は最も懸案すべき事項である．
したがって，Egress Peerから広告される経路は，特定のIP経路情報とSRv6-EPE SIDを関連付けて管理されなければならない．この組み合わせを本稿では“EPE Route”と呼称する．SRv6-EPEの対象トラフィックを生成するコンテンツサーバには，サービス提供前に必要なEPE Routeを伝達する必要がある．また，Egress Peerから広告が停止した経路に関連するEPE Routeは速やかにホストから削除することも求められる．
3.2 Quality-Based Egress Path Decision Making and Traffic Control
EPEコントロールプレーンの機能のうち，第2.4節で述べた「コンテンツの配信品質を最大化するEgress Pathの選択と利用」にあたる役割を“Quality-Based Egress Path Decision Making and Traffic Control”と定義する．
第2.4節で述べたように，Egress Pathを適切に評価するためにはトラフィックを実際に送る必要がある．下記の3つの機能が相互に作用することで，パフォーマンスがより優れたEPE Routeを利用したコンテンツ配信が可能となる．
- ・QoSメトリクスの計測
あるEPE Routeを利用した際のコンテンツ配信のパフォーマンスを，各種QoSメトリクスを収集・蓄積することで計測する．収集するメトリクスはコンテンツの種類や用途に合わせて設定される． - ・品質の良いEPE Routeの選択
収集されたQoSメトリクスを参照し，EPE Provisioning and Reachability Managementから得られた複数のEPE Routeから，コンテンツサービスのQoS基準に基づき，最も適切なEPE Routeを判断する． - ・利用するEPE Routeの設定
選択されたEPE Routeを実際にコンテンツトラフィックが利用するための準備処理を行う．たとえば新たな転送ルールをデータプレーンに設定したり，パケットが通るEPE Routeを直接指定する処理が想定される．これにより，クライアントへのコンテンツの配信経路が変更される．
4. 提案手法
本研究では，第3章で述べたEPEコントロールプレーンの実現手法として“Multipath Transport SRv6-EPE Suite”を提案する．Multipath Transport SRv6-EPE Suiteは大きく分けて2つの要素で構成される．1つ目は“EPE Provisioning and Reachability Management”を担うSRv6 L3VPN，2つ目は“Quality-Based Egress Path Decision Making and Traffic Control”を担うMPTCPである．本章ではこれらの技術の概要と具体的な活用手法を述べる．
4.1 SRv6 L3VPNによるEPE Provisioning and Reachability Management
4.1.1 SRv6 L3VPN
SRv6 L3VPNは，コントロールプレーンにMulti Protocol BGP（MP-BGP），データプレーンにSRv6を使用するL3オーバーレイサービスであり[19]，IPv6 VPN経路[20]を通じて複数テナントのIPv6疎通性を提供する．パケットは各IPv6 VPN経路に付属するSRv6 SIDを用いて，ルータ上の適切なVirtual Routing and Forwarding（VRF）に転送される．この転送にはSRv6 BehaviorのEnd.DT6またはEnd.DT46が利用される[14]．SRv6 L3VPNを有効化したルータでは，ルーティングデーモンがVRFへの転送に必要なSRv6 SIDの発行とフォワーディングルールの作成が自動的に行われる．したがって，第3.1節で述べた“EPE Provisioning and Reachability Management”の機能のうち，「SRv6-EPE SIDの発行・削除」はASBR上のルーティングデーモンが行うことになる．
4.1.2 EPEに利用する経路の取り扱い
Multipath Transport SRv6-EPE Suiteでは，クライアントとのパケットの送受信に際し，非対称的な経路制御を行うことでSRv6-EPEを実現する．
図3は，図1のネットワークでSRv6 L3VPNを用いたSRv6-EPEを行うために必要な経路情報のやり取りを，Egress Peer αとEgress Peer αに関連する部分を抜粋し表したものである．
Fig. 3 Route exchange in the Multipath Transport SRv6-EPE Suite.
Performance Aware EPEを行うためには，各Egress Peerから受信したEgress Pathを区別して保持する必要がある．Multipath Transport SRv6-EPE Suiteは，Egress Peerごとに個別のVRFをサーバに用意することでEgress Pathを区別する．ASBRからがEgress Peerから受信した経路はSRv6-EPE SIDを含むIPv6 VPN経路（EPE Route）として，ルートリフレクタを経由してコンテンツサーバに配布され，それぞれのVRFにインストールされる．この一連の経路共有プロセスは，“EPE Provisioning and Reachability Management”の役割の一部として，ASBR，ルートリフレクタ，コンテンツサーバのルーティングデーモンが分散的に協調動作して行われる．
一方で，サーバがクライアントから受信するパケットには，CSPからEgress Peerに広告される通常のIPv6経路が使用される．ASBRの各Egress Peer接続インタフェースは専用のVRFに属しているため，受信したCSPネットワークの経路はこのVRFにルートリーク*1される．
第3.1節で述べたように，SRv6-EPE SIDの上位ビットはASBRを示すSRv6 Locatorプレフィックスが占めている．“EPE Provisioning and Reachability Management”の構成機能の1つである「SRv6 Locatorの発行と到達性の管理」を充足するためには，ASBRを示すSRv6 Locatorプレフィックスへの経路を，通常のIPv6経路としてCSPネットワーク内に広告する必要がある．
4.1.3 Policy Based RoutingによるEgress Pathの利用
コンテンツサーバには通常のインタフェースアドレス（以後デフォルトアドレス）に加えて，Egress Peerごとに特殊なIPアドレス（以後EPE専用アドレス）を設定する．EPE専用アドレスによるアウトバウンド通信には，対応するEgress Peerから受け取ったEgress Pathのみが明示的に利用される．図4は，図1のネットワーク上のコンテンツサーバの，EPE専用アドレスの利用手法を示したものである．サーバはEgress Peer α, β, γから受信した経路*2がEPE Routeとしてそれぞれ保持されるVRFと，3つのEPE専用アドレスが属する通常のルーティングテーブル（デフォルトVRF）を持つ．EPE専用アドレスを使用する通信は，デフォルトVRFに設定されたPolicy Based Routing（PBR）により，対応するVRFにリダイレクトされる．
Fig. 4 Relationship between VRFs and EPE-specific addresses in a content servers.
4.2 Mulitpath TCPによるQuality-Based Egress Path Decision Making and Traffic Control
4.2.1 MPTCP
MPTCPは，複数のTCPコネクションを統合して1つのセッションとして利用するTCP拡張であり[21]，複数のアクセス回線の帯域の有効活用や，疎通性が不安定な環境下での冗長性の確保を目的とした適用が進んでいる[22]-[25]．MPTCPが動作するホストは，MPTCPの通信に利用可能なインタフェースアドレスを，“MPTCP Endpoint”として管理する．通常は異なるアクセス経路ごとにEndpointが設定される．MPTCPセッションを確立したホスト間でEndpointの情報を交換することにより，セッションに参加するTCPコネクション（Subflow）の確立と管理が行われる[26]．
4.2.2 MPTCPセッション確立までの流れ
図5は，図1のCSP上のサーバがMultipath Transport SRv6-EPE Suiteを用いてコンテンツサービスを提供する際の，トラフィックの流れを簡易的に示したものである．本提案手法ではコンテンツサーバとクライアントとの間でMPTCPセッションを確立し，トラフィックを送出するSubflowをパケットごとに選択することで，コンテンツの配信品質の最大化を目指す．
Fig. 5 Traffic flow in the Multipath Transport SRv6-EPE Suite.
第4.1節でも述べたようにコンテンツサーバは二種類のアドレス（デフォルトアドレス，EPE専用アドレス）を有する．デフォルトアドレスはその時点でBGPベストパスとなるEgress Pathを，EPE専用アドレスは対応するEgress Peerから受信したEgress Pathを常に利用して，アウトバウンド通信が行われる．なお，EPE専用アドレスが利用するEgress Pathは，第4.1節で記した仕組みにより事前にコンテンツサーバにインストールされる．
本提案手法ではこれらのアドレスそれぞれでSubflowを確立する．たとえば図1のネットワークでは，CSPはα, β, γの3つのEgress Peerを有するため，BGPベストパスを常に利用するSubflowと，Egress Path α, β, γを明示的に利用する3つのSubflowの，合計4つのSubflowが利用されることになる．
本提案手法における各Subflowが確立されるまでの手続きについて述べる．はじめに，クライアントはコンテンツサーバのデフォルトアドレスに対してTCPコネクション確立を要求する．このTCPコネクション（以後初期コネクションと呼ぶ）が確立された後，クライアントがMPTCPをサポートしていれば，MPTCPセッションが確立される．この初期コネクションは以後Subflowの1つとなり，他のSubflowが確立されるまでのコンテンツ配信を担う．なお，第3.1節で述べたように，すべてのEgress Pathから任意のクライアントまで必ずしも到達可能であるとは限らない．そのためコンテンツサーバは，特定のEgress Pathに紐づいたEPE専用アドレスではなく，BGPによってクライアントへの到達性が維持されるデフォルトアドレスで初期コネクションを確立する必要がある．
次に，サーバは各EPE専用アドレスをクライアントに通知し，これらのアドレス宛の新たなTCPコネクションが確立される．これらはSubflowとしてMPTCPセッションに追加される．しかし，前述したようにそれぞれのEPE専用アドレスは特定のEgress Peerと紐づいたアドレスであるため，実際にコネクションが確立可能で，Subflowとして利用できるかどうかは，対応するEgress Peerからクライアント宛の経路を受信しているかに依存する．
4.2.3 MPTCPスケジューラによるトラフィック制御
サーバ上のアプリケーションから送出されたコンテンツトラフィックは，カーネル内で動くMPTCPスケジューラによって各Subflowに分配される．スケジューラは各SubflowのTCPメトリクスを基に，その時点で最適なSubflowを選択し，パケットごとに送信先を決定する．すなわち，第3.2節で述べたQuality-Based Egress Path Decision Making and Traffic Controlのうち，「QoSメトリクス計測」はカーネルのTCPスタックが，「品質の良いEPE Routeの選択」と「利用するEPE Routeの設定」はMPTCPスケジューラが担う．
パケットを送信するSubflowの選択はMPTCPスケジューラごとの戦略に基づいて行われる．著名なスケジューリング戦略には，“Round-Robin”，“Lowest-RTT-First” [27]，および“BLEST” [28]などがある．本提案手法は，MPTCPスケジューラの戦略をコンテンツの品質基準に合わせて変更することで，幅広いアプリケーションに最適化する柔軟性を提供する．よって，CSPが本提案手法を展開する際に，コンテンツの種類に合わせて特別に実装および保守しなければならないコンポーネントはMPTCPスケジューラのみになる．これは第2.4節で述べたEPEコントロールプレーンの要求事項の1つである「展開の容易性」に合致する．
なお，デフォルトアドレスを利用したSubflow（初期コネクション）は，いずれかのEPE専用アドレスを利用したSubflowと同じEgress Peerを介して転送される．EPE専用アドレスを利用したSubflowにはSRv6による処理が追加で発生するため，仮にBGPベストパスと一致するEPE Routeがパフォーマンスの観点で最適である場合は，初期コネクションが選択されやすくなることが想定される．本手法はコンテンツ配信品質の向上を目的としているため，BGPベストパスを常に利用するSubflowを「品質の良いEPE Routeの選択」から排除せず，EPE専用アドレスによるSubflowと並列して利用するように設計する．
4.3 Multipath Transport SRv6-EPE Suiteの実装
第5章で後述する評価実験を行うため，Multipath Transport SRv6-EPE Suiteに必要なシステムを備えたコンテンツサーバを実装した．本節では本実装における各コンポーネントの概要を述べる．図6はコンテンツサーバ上で動作するコンポーネント群と，OS内の関連する機構との相互関係を表したものである．
Fig. 6 Components of a content server implementing the Multipath Transport SRv6-EPE Suite.
- ・MPTCP実装
第4.2節で示したように，本提案手法では“Quality-Based Egress Path Decision Making and Traffic Control”にMPTCPを活用する．第5章で後述する評価実験では，MPTCPv1 [21]を実装したLinux仮想マシンをコンテンツサーバとして利用する．Linuxカーネルには2023年10月時点で最新の開発版のもの（6.6.0-rc4*3）を採用する．なおこの開発版のカーネルでは，TCPの輻輳制御機構をカスタマイズするためのeBPFプログラム（BPF STRUCT_OPS）[29]を導入してMPTCPスケジューラを変更することが可能であるが[30]，評価実験にはカーネル内に標準で実装されているBLEST [28]をベースとしたスケジューラ[31]を使用する． - ・BGPデーモン
SRv6 L3VPNによる“EPE Provisioning and Reachability Management”を実現するためには，CSP AS内で有効なEPE RouteをルートリフレクタからBGP経由で収集し，サーバ内の各VRFにインストールする必要がある．本研究ではBGPデーモンにFRRouting*4を利用する． - ・Endpoint Manager
第4.1節で述べたように，Multipath Transport SRv6-EPE SuiteではEPE Routeを明示的に利用するために，EPE専用アドレスとそれぞれのアドレスをVRFにリダイレクトするPBRルールが必要である．本研究ではEPE専用アドレスの設定やVRFの作成，MPTCP Endpointの管理およびPBRルールの適用を一括して行うSDNエージェントを独自に実装した．
5. 評価
本章では，本稿が提案するMultipath Transport SRv6-EPE Suiteが，第2.4節で述べたEPEコントロールプレーンの要求事項を満たしているかどうかを検証する．EPEコントロールプレーンの要求事項には，（1）コンテンツ配信品質の向上，（2）通信環境の変化への追従性，（3）多様なコンテンツへの柔軟性，（4）展開の容易性の4つの項目が含まれる．
第4.2節で示したように，本提案手法は，MPTCPスケジューラの戦略を変更することでEgress Pathの選択基準を変えることが可能である．さらに，同一ネットワーク上で異なるスケジューラを用いた複数のコンテンツサーバを同時に運用することも可能である．したがって，品質基準が異なるコンテンツアプリケーションに幅広く適用可能であり，「（3）多様なコンテンツへの柔軟性」を有していると言える．
また，本提案手法は，CSP ASとEgress Peer間で標準的なBGPによる経路交換以外の情報交換を必要としないため，CSPは他のASに協力を仰ぐことなく導入が可能である．加えて第2.2節で述べたように，SRv6-EPEは既存のIPv6ネットワークへ容易に導入でき，EPEを利用しないトラフィックとの共存が可能である．これらの理由から，本提案手法は「（4）展開の容易性」の要求を満たすアプローチであると言える．
以後，本章では本提案手法が「（1）コンテンツ配信品質の向上」と「（2）通信環境の変化への追従性」を満たすことを定量的に検証するため，以下のように仮想環境での評価実験を行う．
- (1) 実験シナリオ1：ネットワーク品質がサービス提供中に変化しない場合
異なる通信品質を持つEgress Pathが存在する場合において，本提案手法が適切なEgress Pathを動的に発見および利用することを確認し，「（1）コンテンツ配信品質の向上」を実現可能か検証する． - (2) 実験シナリオ2：ネットワーク品質がサービス提供中に変化する場合
コンテンツサービス提供中にEgress Pathの通信品質が変化する状況を想定する．本提案手法がこのような環境下でも配信品質の劣化やサービスの中断を回避する，「（2）通信環境の変化への追従性」を有しているか検証する． - (3) 実験シナリオ3：BGP経路が変化する場合
CSP ASが利用できるEgress Pathに変化が生じた場合でも，EPEコントロールプレーンの2つの役割のうち「EPE Provisioning and Reachability Management」機能が本提案手法に適切に備わっており，EPE Routeが動的に更新されるかを確認する．この実験シナリオでは本提案手法の「（2）通信環境の変化への追従性」を検証する．
また，実際のインターネット環境での本提案手法のフィジビリティ評価を目的とした評価実験も行う．WIDEプロジェクト*5が運用するASから，様々なISPに所属する実験用クライアントに対してコンテンツ配信を行い，より実環境に近い状態での本提案手法の有用性を実践的に評価する．
5.1 仮想環境でのMultipath Transport SRv6-EPE Suiteの基本機能の検証
5.1.1 実験環境
図7に示される本評価実験の仮想環境トポロジーは，第2.1節で設定したトポロジーを単純化し，SRv6 L3VPN経路を集約・配布するルートリフレクタを加えたものである．CSP ASとTransit ISP A/B間，Client ISPとTransit ISP A/B間でEBGPピアを確立し，経路情報を交換する．CSP ASからClient ISPへのBGPベストパスはTransit A経由とする．以後のシナリオでは，リンクaとbの帯域幅を制限し，擬似的に各Egress Path間で通信品質の差異が生じている状態を再現する．なお，この仮想環境はLinuxのNetwork Namespace機能[32]によって1台のLinuxマシン上に構築する．各仮想ノードは第4.3節に述べたものと同じBGPデーモンを利用する．
Fig. 7 Network topology for the evaluation experiments in a virtual environment.
5.1.2 評価用コンテンツトラフィック
本評価実験では，下記の2つの異なる様式のトラフィックをコンテンツサーバからクライアントに送出させ，それぞれ通常のTCPとSRv6-EPEによるMPTCP（以後“MPTCP EPE”と呼ぶ）を利用した際のスループットを比較分析するために使用する．
- ・Constant Bit Rate（CBR）トラフィック
ライブストリーミングビデオのような一定速度でのコンテンツ配信を想定し，25 Mbpsのトラフィックをコンテンツサーバからクライアントに向け30秒間送出する．CBRトラフィックの生成にはiperf*6を利用する． - ・Bandwidth-Intensive（BI）トラフィック
可能な限り帯域を使用するWWWのようなコンテンツを想定し，クライアントはHTTP GETリクエストによりコンテンツサーバから100 MBのバイナリデータをダウンロードする．BIトラフィックの生成には，Pythonで動作する標準的なWEBサーバ*7を利用する．
5.1.3 SRv6 FlowStats
SRv6-EPE環境ではコンテンツサーバのアウトバウンドトラフィックはSRv6でカプセル化されるため，トラフィックが実際にどのEPE Routeを使用したかを追跡することが困難である．本評価実験中のMPTCPスケジューラの振る舞いを正確に把握するため，独自のモニタリング用アプリケーション（“SRv6 Flow Stats”）を開発した．
図6に示すように，SRv6 Flow Statsはコンテンツサーバ上のMultipath Transport SRv6-EPE Suiteの主たるコンポーネントとは独立して動作する．eBPF tc classifier [33]を利用して，コンテンツサーバの物理インタフェースにeBPFプログラムをアタッチし，パケットが通過するごとにインナーパケットの5-tuple*8をキーとしてeBPF Mapにカウンタを記録する．ユーザスペースのアプリケーションは100 msごとにこのeBPF Mapから統計情報を取得し，差分をログファイルに保存する．これにより，Subflow（TCPコネクション）ごとにトラフィック流量を正確に計測することができる．
5.1.4 実験シナリオ1：ネットワーク品質がサービス提供中に変化しない場合
本実験では，ネットワークの品質がサービス提供中に変化しない場合でのMultipath Transport SRv6-EPE Suiteの基本性能を確認する．図7のトポロジでのリンクaとbの帯域を制限して，Egress Pathの通信品質を2種（高品質パス，低品質パス）組み合わせた4つのパターンを表1のように設定した．なお，本節で設定したCBRトラフィックが要求する帯域（25 Mbps）に対して，高品質パスではこの要求を満たすリンク帯域（30 Mbps）を，低品質パスではこの要求に不足するリンク帯域（15 Mbps）を設定した．
Table 1 Parameters for each pattern in scenario 1.
図8に，これらのパターンで発生させたコンテンツトラフィックのL7 goodput*9を，TCPと本提案手法におけるMPTCP（MPTCP EPE）で比較して示す．緑色の点線はCBRの理論上の最大スループットである25 Mbpsを示している．CBRとBIの両方で，MPTCP EPEは通常のTCPと同等以上のL7 goodputを達成している．特にパターン1.3や1.4のようなBGPベストパスが低品質な状況でも，MPTCP EPEは理論値に近いL7 goodputを記録している．これはMultipath Transport SRv6-EPE Suiteが利用可能なEgress Pathを効果的に発見し，BGPベストパスに依存せずに帯域を有効に利用できることを示している．
Fig. 8 Scenario 1: Comparison of L7 goodput between TCP and MPTCP across different patterns.
5.1.5 実験シナリオ2：ネットワーク品質がサービス提供中に変化する場合
本実験シナリオでは，サービス提供中の配信経路の品質変化に対するMultipath Transport SRv6-EPE Suiteの効果を検証する．実験シナリオ1と同じネットワークを利用し，テストトラフィックがCBRの場合はサービス開始4秒後，BIの場合は9秒後に表2に示したような品質変化を発生させ，トラフィックの振る舞いを観察した．
Table 2 Parameters and their changes for each pattern in scenario 2.
図9は，サービス開始からの経過時間（X軸）ごとの各フローのスループット（Y軸）とセッション全体のスループットの平均値（各グラフ上部）を，トラフィック種別ごとに表したものである．通常のTCPはBGPベストパスのみを利用するが，MPTCP EPEでは，BGPベストパス・Transit A・Transit Bの3つに対応するSubflow*10が用いられる．赤・青・水色の各線はそれぞれのSubflowのスループットを，紫の線はそれらの合計値を示している．
Fig. 9 Scenario 2: Temporal throughput changes for each egress path.
パターン2.1（図9の1行目）では，BGPベストパスの品質が悪化（リンクaの帯域減少）した際，通常のTCPはCBRとBIの双方でスループットを落としている．しかし，MPTCP EPEを使用したCBRでは，品質変化前はBGPベストパスとTransit AのSubflowを利用し，変化後はTransit Aの代わりにTransit BのSubflowへ切り替え，要求帯域（25 Mbps）のスループットが維持されている．BIでも，MPTCP EPEは品質変化前後で理論上の最大スループットに近いパフォーマンスを維持し（変化前約45 Mbps，変化後約30 Mbps），環境変化に適応している．
パターン2.2（図9の2行目，BGPベストパスの品質が良化）では，MPTCP EPEはCBRで要求帯域（25 Mbps）に近いスループットを維持し，BIでは適応的にスループットを増加させている．一方，通常のTCPによるCBRは，BGPベストパスの品質良化前にはCBRの要求値に達せず，良化後は要求値を超えるスループットが観測されている．これは品質変化前にTCPによりバッファリングされたデータが，品質変化後に送信された影響と考えられる．また，パターン2.3と2.4（図9の3, 4行目）では，MPTCP EPEは冗長パスを有効に活用し，品質変化後にはTransit A・Transit Bの双方の合計帯域（45 Mbps）に近い値のスループットを出していることが分かる．
以上により，Multipath Transport SRv6-EPE Suiteは経路上の品質変化に線形に追従し，サービス中断や品質劣化を可能な限り回避する能力を有することが分かった．
5.1.6 実験シナリオ3：BGP経路が変化する場合
第3.1節で述べたように，適切にEPEを運用するためには，CSP AS内で利用可能なEgress Pathの変化に応じて，コンテンツサーバ上のEPE Routeを迅速に更新することが求められる．本実験シナリオではCSP ASがEgress Peerから受信するBGP経路が変化する場合を想定し，Multipath Transport SRv6-EPE SuiteにおけるSRv6 L3VPNの通信環境変化への追従性を検証する．
図7のトポロジにおいて，クライアントISPのルーターからTransit Aに対する経路広告ポリシーが変更（以後経路変更と呼称する）されるケースを仮定する．Egress Peer AがクライアントISPから受信する経路が変わると，Egress Peer AからCSPのASBR 1へ広告される経路にも変更が及ぶ．これに伴ってASBR 1は自身のルーティングテーブルを更新し，ルートリフレクターを介してコンテンツサーバに経路変更が伝搬され，最終的にコンテンツサーバ上の対応するEPE Routeが更新される．
第4.1節で述べたように，コンテンツサーバのEPE専用アドレスによる通信は，該当するEgress Peerに由来するEPE Routeを参照して，明示的にそのEgress Peerを経由して配送される．コンテンツサーバのEPE専用アドレスによるSubflowは，MPTCPセッション確立時点でクライアントに到達可能な場合にのみ確立される．たとえばコンテンツサービス提供中にクライアントに対するEPE Routeが削除された場合，それを参照しているEPE専用アドレスによるSubflowは利用できなくなる．ネットワーク品質がサービス提供中に変化する場合と同様に，MPTCPスケジューラによる他のSubflowへトラフィックの再割り当てが行われる．
本シナリオではクライアントISPでの経路広告ポリシーの変更から，コンテンツサーバが保持するEPE Routeへ変更が適用されるまでに掛かる時間を計測し，本提案手法の追従性を定量的に評価する．EPE Routeの変更の計測には，ルーティングテーブルの変更をリアルタイムに検知可能なiproute2の“ip-monitor”機能[34]を利用した．また，この経路広告ポリシー変更から，CSP AS内でBGPベストパスが収束*11するまでの時間も合わせて計測し，これらの比較を行う．
本実験シナリオで行った2つの経路変更のパターンを表3に示す．パターン3．1はクライアントISPがTransit AS Aに対して経路を広告していない状態から広告する状態への遷移を，パターン3．2は広告している状態から広告しない状態への遷移を想定したものである．それぞれ100回ずつ試行し，EPE Routeの変更適用とBGP経路収束の双方を同時に計測した．
Table 3 Patterns of route changes in scenario 3.
図10は，本実験シナリオの各パターンにおいて，コンテンツサーバ上のEPE Routeに変更が適用されるまでに掛かった時間とBGPベストパス収束までの時間の計測結果の分布を，それぞれの四分位数に基づき比較したものである．箱の底辺は第一四分位数を，上辺は第三四分位数を示し，箱の中央線は中央値を表す．ヒゲは外れ値を除いた最小値と最大値の範囲を示し，白い丸点は外れ値を表す．クライアントISPによる経路広告ポリシー変更後，パターン3.1における所要時間の中央値はそれぞれ190 ms程度，パターン3.2においては310 ms程度であった．両パターンともに，EPE Routeの変更適用とBGPベストパス収束との間に大きな差異はみられない．
Fig. 10 Scenario 3: Distribution of time required for BGP route changes.
これらの結果より，Multipath Transport SRv6-EPE Suiteは通常のIPv6ルーティングと同等の経路変化への変更追従性を有していることが明らかになった．
5.2 実際のインターネットにおけるコンテンツ配信試験
本節では，Multipath Transport SRv6-EPE Suiteのインターネット環境での活用を想定した評価実験に関して述べる．実際のコンテンツ配信に近い環境における本提案手法の有用性と課題を明らかにする．
5.2.1 実験環境
図11に本評価実験に利用したネットワークを示す．WIDEプロジェクトが運営する実験用AS（WIDE AS）にコンテンツサーバを設置する．WIDE ASでは1台のASBRが2つのEgress Peer（Transit α，Transit β）と接続している．本実験では様々なISPに接続したサンプルクライアントを用意し，WIDE ASからコンテンツサービスの提供を行う．WIDE AS内のコンテンツサーバとASBRは100 Gbpsで接続しており，本評価実験のために十分な収容能力を持つ．
Fig. 11 Network topology for the evaluation experiments using the actual internet environment.
通常のTCPとMPTCP EPEを利用したコンテンツ配信を同日同時刻帯にそれぞれ10回試行し，配信方式による提供品質の差異を比較する．後述するTCPの並列化によるオーバーヘッドを検証するために，本実験ではiperfによって生成したBIトラフィックを利用した．通常のTCPではBGPベストパス選択ルールにより選択されたEgress Pathを，MPTCP EPEではTransit αとTransit βの両方のEgress Pathを経由して配信される．
表4に本研究においてサンプルクライアントが接続する各ISPの基本情報を示す．日本国内のMNO事業者*124社と，国内で固定回線でのインターネットアクセスを提供する事業者1社，そしてクラウドサービスを提供する国内外の事業者4社をクライアントのISPとした．
Table 4 Overview of client ISPs in the content delivery evaluation on the actual internet.
表5にクライアントデバイスとして利用したホストの詳細なスペックを示す．モバイル事業者および固定回線事業者に接続する際には共通の物理マシンを，クラウド事業者の場合はその事業者が提供しているVirtual Private Server（VPS）サービスによる仮想マシンを利用した．本評価実験はISP事業者間での性能を直接比較することでなく，同一ISPの配信方式間での提供品質の違いを把握することを目的としているため，実験に利用した仮想マシンのスペックは一致していない．なおすべてのホストのOSにはUbuntu 22.04.03 LTSを採用した．
Table 5 Specifications of content servers and client devices used in the content delivery evaluation on the actual internet.
5.2.2 通常のTCPとMPTCP EPE間のL7 goodputの比較
図12および図13は，各ISPごとの配信結果（L7 goodput）の分布を計測種別（通常のTCPもしくはMPTCP EPE）ごとに四分位数に基づき表したものである．箱の底辺は第一四分位数を，上辺は第三四分位数を示し，緑の線は中央値を表す．ヒゲは外れ値を除いた最小値と最大値の範囲を示し，白い丸点は外れ値を表している．また，通常のTCPに対するMPTCP EPEの改善割合（中央値比）を各グラフ上部に示している．
Fig. 12 L7 goodput of each mobile ISP.
Fig. 13 L7 goodput of each fixed line and cloud ISP.
全体を通して，本実験環境では多くのISPで，MPTCP EPEのほうがより高品質なサービス提供を行えていることがみて取れる．9つのISP中6つで10%以上の品質向上をみせたほか，内4つのISPでは50%以上の顕著な向上がみられた．
しかしながらISP AおよびISP Eでは，MPTCP EPEを使用することにより通常のTCPより約8%ほど品質が悪化している．これはEPEでより優れたEgress Pathを選択することで得られる利得よりも，MPTCP EPEに掛かる処理のオーバーヘッド，あるいはTCPフローの並列化による負荷が大きくなっていることが推察される．
5.2.3 ISP EにおけるTCPコネクション並列化の負荷検証
品質悪化率が最も高かったISP Eを対象とし，通常のTCPを並列化して同様の条件でコンテンツを提供する追加実験を行った．本実験ではiperfコマンドの並列化オプション*13を利用して，通常のTCPによるコンテンツ配信のコネクション並列化を行う．
図14に，ISP Eに接続したクライアントに対して，iperfのデータ用TCPコネクションを1，3，6，9，12に並列化してコンテンツ配信を行った際のそれぞれのL7 goodputを示す．最も左側に，参考までにMPTCP EPEでの結果を追記している．TCPコネクションを並列化するに従って，L7 goodputが逓減していることが確認できる．
Fig. 14 Comparison of L7 goodput between parallelized TCP and MPTCP EPE in ISP E.
今回の実験環境で利用したiperfでは，実際の計測用トラフィックが乗るTCPコネクションの他に，メトリクスを相互に交換するための制御用のTCPコネクションを確立する[35]．本実験環境におけるMPTCP EPEは，1つのMPTCPセッションで合計3つのSubflow（BGPベストパスを利用するSubflow,Transit αのみを利用するSubflow, Transit βのみを利用するSubflow）が確立されるため，MPTCPを利用する際には6つのTCPコネクションが確立されることになる．
図14より，合計6つのTCPコネクションを確立するMPTCP EPEと，合計7つ（制御用TCPコネクションと6つのデータ用TCPコネクション）のTCPコネクションを利用した際のL7 goodputはおおよそ近しい値になっていることが確認できる．すなわち，ISP Eの環境下ではTCPコネクションを並列化することによる負荷が顕著であり，これに伴ってMPTCP EPEのスループットが低下していると言える．
本追加実験を通じて，MPTCP EPEを利用してユーザにコンテンツを提供することが，必ずしも提供品質の改善につながるわけではないことが明らかになった．
5.2.4 まとめ
本評価実験を通じて，Multipath Transport SRv6-EPE Suiteが実際のインターネットでのコンテンツ配信環境においても，多くの場合で配信品質向上を見込めることが明らかになった．一方で，一部の環境下においては，TCPコネクションが並列化されることによって配信品質の低下を招く可能性があることが分かった．
6. 関連研究
本章では，本提案手法と提案手法の要素技術（EPEとMultipath Transport）に関連する研究とを比較し，提案手法の特徴をより明らかにする．
6.1 Egress Peer Engineering
EPEは，BGPベストパスセレクションによらずに，AS外に向かうトラフィックを柔軟に制御する技術である．一般的な他のトラフィックエンジニアリング技術と比較して，自らが管理するネットワーク外の通信経路の選択にフォーカスしている点が特徴的である．
6.1.1 EPEの活用
EPEは，その特徴から様々な用途に用いることができる．Espresso [36]では対外接続リンクの輻輳回避を，BGP-NCM [37]では帯域の有効活用を目的とし，EPEが用いられている．これらの手法は他のASとの接続リンクの状態を基準にEgress Pathを選択する取り組みであり，我々の手法のようにクライアントまでのE2Eの品質向上を目的としたものではない．
また，中村らの研究[18]や筆者らの研究[12]は，インターネットの品質測定を目的としており，EPEを複数のBGPパスを比較するために利用している．これらの手法によってE2Eでの性能測定をもとにEgress Pathの評価ができる一方，実際にパフォーマンスに優れると判断されたEgress Pathの具体的な活用手法は取り組みのスコープとされていない．
EPEの具体的な制御手法として，BGP Link State（BGP-LS）のプロトコル拡張[38]と，それを用いた運用モデルが標準化されている[11]．しかしながらこれらの標準はあくまでEPEの集中管理を行う際の一般論についてのみ記述しており，具体的な配信品質の向上手法や，経路や品質の変更に追従する手法に関する検討が不足している．
6.1.2 EPEを用いたコンテンツの品質向上
EPEでは，トラフィックの配信に利用するEgress Pathを任意に切り替えることで，クライアントまでのE2Eの通信品質を変化させることができる．この特性を利用し，通信品質の向上を目指す取り組みがいくつか存在する．Edge Fabric [39]は，外部接続リンクの有効活用とコスト最小化を主目的としているものの，実際のプロダクションコンテンツの配信品質をベースにEgress Pathに重み付けを行う．筆者らの過去の研究であるCOFFEE [40]では，データプレーンにSRv6を利用し，Kubernetesベースのコントローラを利用することでEPEによるコンテンツ配信品質の向上を実現している．
しかしながらこれらの手法にも未解決の課題がある．Facebookの手法はAS全体で統一して経路選択戦略を決定するため，本稿での提案手法のように，コンテンツやクライアントに合わせて選択基準を柔軟に組み替えることができない．COFFEEは経路制御のために専用のSDNフレームワークが必要となるため，開発・導入・運用に掛かるコストが高く，第2.4節で定義したEPEコントロールプレーンの要求事項である「展開の容易性」に課題がある．本稿で提案するMultipath Transport SRv6-EPE Suiteは主要なコンポーネントに既存のプロトコル実装を活用しているため，COFFEEと比較して開発・導入・運用に掛かるコストが低い．また，COFFEEはセッションの開始前に過去の統計情報からトラフィックを送出するEgress Pathを決定するため，サービス中にEgress Pathの通信品質が変動した場合に，サービス断や配信品質の劣化を招く可能性がある．Multipath Transport SRv6-EPE SuiteではリアルタイムにEgress Pathが評価・選択されるため，サービス中の通信品質の変化に追従できる．
6.2 Multipath Transport
Multipath Transportは，トランスポート層でコネクションの多重化とスケジューリングを行うプロトコルの総称である[41], [42]．代表的なプロトコルとして，MPTCP [21]，MP-QUIC [43]，MP-DCCP [44]などが広く利用されている．
6.2.1 Multipath Transportの活用
一般に，Multipath Transportは複数のリンクの帯域のアグリゲーションや冗長化を目的として利用される．Multipath Transportが複数の経路を併用できる性質に着目し，帯域だけでなく，遅延やジッタなど様々なQoSメトリクスを向上させる取り組みが存在する．
たとえばNikraveshらの研究などでは[45]，MPTCPを用いて複数のモバイル回線を束ねることで，スループットと冗長性の向上を実現している．Hurtigらの研究の例[46]では，モバイル回線とWi-Fiなど，複数のインタフェースを持つ機器にMPTCPを適用しWebコンテンツを表示するまでの遅延を削減している．また，このようなアプローチは他のプロトコルを利用しても実践されている[47]．
金子らの研究[48]では，WebRTCにより複数のモバイル回線に映像を重複して配送することで，自動車のロバストな遠隔監視アプリケーションを実装している．
X-LINK [49]は，多くの動画コンテンツによって構成されたeコマースサービスのQoE向上を目的として，MP-QUICを拡張し大規模なデプロイメントを行った研究である．クライアントアプリケーションからのQoEコントロールシグナルによって，コンテンツサーバのスケジューラがコンテンツを送出する宛先アドレスを選択する機構が導入されており，サービス応答性やスタビリティの向上が実現されている．
これらの既存の研究がフォーカスしているのはクライアントデバイスのアクセス回線の冗長化・抽象化であり，Multipath Transport SRv6-EPE Suiteのように品質に応じたBGP経路の選択と利用に用いることを目的としていない．
また，QualitySDN [50]では，SRネットワーク上でMPTCPサブフローを転送することにより，QoEを考慮したE2Eの転送を行っているが，制御が可能な範囲はSRドメインの中に限られており，我々の研究のように，管理ドメイン下にない通信経路上での利用はできない．
6.2.2 Multipath Transportスケジューラ
Multipath Transportには，トラフィックを送出するSubflowを選ぶスケジューラを組み替えることで，通信品質の更なる向上を目指す余地があると言われている[51]．
たとえばLinux Kernelには，Subflowを一定の順序で利用するものや複数のパスに必ず同時送信するもののようなプリミティブなスケジューラから，経路間での公平なデータ配分を目的としたwVegas [52]，ヘテロジニアスな品質のアクセス回線でのパフォーマンス向上を目的としたBLEST [28]やECF [53]など，多種多様なスケジューラがこれまでに実装されてきた．
これらのアプローチは幅広いアプリケーションに広く利用可能なものであるが，近藤ら[54]が既存の一般的なスケジューラのビデオストリーミングでの問題を提起しているように，一部のアプリケーションでは従来のトランスポート層のメトリクスのみを利用したスケジューラを用いることが限界を来していると指摘されている[55]．そのため近年ではアプリケーションのユースケースに特化させたスケジューラ実装も広く提案されている．
たとえばビデオストリーミングの領域では，アプリケーション層や動画ストリーミングのメトリクスを利用した新しいアプローチが提案されている[55], [56]．また，Virtual Reality用のユースケースに特化したスケジューリングを行うフレームワークも提案されている[57]．
このように様々なスケジューラがこれまでに提案されているが，MPTCPを利用するMultipath Transport SRv6-EPE Suiteでも，アプリケーションのユースケースに合わせたスケジューラ戦略を導入できる．第4.3節でも述べたように，本研究で利用した最新のLinuxカーネルの開発版では，eBPFを用いて運用者が独自のスケジューラを導入することができる．たとえば，eBPF Map [58]によりユーザランドの任意のアプリケーションからスケジューリングに介入し，個別のコンテンツアプリケーションのメトリクスを利用したスケジューリング戦略を採用するような使い方も想定される．
7. 今後の展望
本研究ではMultipath Transportのプロトコルとして，Linuxカーネルに標準的に実装されているMPTCPを選定したが，他のプロトコルを用いた際の性能評価は今後の課題である．特に，Multipath QUICはMPTCPと比較してパケット損失に対して優れた結果を示しているとの研究があり[59]，プロトコルの違いによる振る舞いの違いについての検証が期待される．加えて，従来のMultipath Transportのユースケースのように，クライアントデバイスが複数のアクセス回線を有する場合での本提案手法のパフォーマンスに関しても，さらなる実験と考察が必要となるだろう．
また，実際のコンテンツ配信では，アプリケーションごとに異なる品質基準が要求される場合がある．本研究が提案したMultipath Transport SRv6-EPE Suiteでは，MPTCPスケジューラを変更することにより，異なる要求に応じた柔軟な経路選択が可能である．ユーザの体感品質に強く関連するQoSメトリクスを明らかにし，そのようなメトリクスを利用した適切なMPTCPスケジューラを選択することが求められる．第6章でも述べたように特定のアプリケーションに最適化されたスケジューラに関する研究は数多く行われているが，これらのスケジューラをMultipath Transport SRv6-EPE Suiteにて利用した際の有用性の評価が今後の課題となる．
加えて，本研究での評価実験を通じて，本提案手法を利用することにより逆に配信品質の劣化を招く環境が一部に存在することも明らかになっている．今後はより多様な環境で本提案手法の実証実験を行い，パフォーマンス劣化の原因を明らかにしていく．それに基づき，クライアントISPの環境の特性を判断してコンテンツ提供方式をダイナミックに切り替える機構を取り入れることで，本提案手法をより幅広く利用することができるようになるだろう．
そして筆者らの過去の研究[12]では，共通するISPのユーザ間で，適したEgress Pathが共通する傾向があることが分かっている．クライアントISPごとに統計情報を蓄積することで，より効率的にEgress Pathを選択する技術も考えられる．
8. 結論
本研究では，CSPのネットワークにおいてパフォーマンスに基づいた経路選択を行うための機構を「EPEコントロールプレーン」と定義し，必要な機能を明確にしたうえで，MPTCPとSRv6 L3VPNを利用した“Multipath Transport SRv6-EPE Suite”を提案した．
本提案手法の基本性能を検証するために，CSPのネットワークを模した仮想環境での評価実験を行った．本評価実験ではBGPベストパスのみを利用した従来のコンテンツ配信と，Multipath Transport SRv6-EPE Suiteによるコンテンツ配信のパフォーマンスを比較し，すべてのテストケースにおいて本提案手法が従来のコンテンツ配信の同等以上の性能を有することが確認できた．また，いくつかのケースにおいてはスループットが大きく向上し，かつサービスの安定性向上に寄与することが確かめられた．
さらに，日本の主要なモバイルISP4社を含む9つのISPに接続するサンプルクライアントに対して，インターネットを介してコンテンツサービスを提供する実環境での評価実験も実施した．本実験環境においては，9つ中6つのISPに接続したサンプルクライアントで，従来のコンテンツ配信環境と比較してスループットが大きく向上することが明らかとなった．
謝辞 本研究について，日頃から助言を賜りましたWIDEプロジェクトやvSIX WGのメンバー，実験リソースを提供いただいたさくらインターネット株式会社，株式会社ブロードバンドタワー，NTTコミュニケーションズ株式会社にこの場をお借りし感謝申し上げます．
参考文献
- [1] Akamai: Measuring Video Quality and Performance: Best Practices, Technical report, Akamai (2020).
- [2] Schlinker, B., Cunha, I., Chiu, Y.-C., Sundaresan, S. and Katz-Bassett, E.: Internet Performance from Facebook's Edge, Proc. of the Internet Measurement Conference (IMC '19), New York, NY, USA, Association for Computing Machinery, pp.179–194 (online), DOI: 10.1145/3355369.3355567 (2019).
- [3] Rekhter, Y., Hares, S. and Li, T.: A Border Gateway Protocol 4 (BGP-4), RFC 4271 (2006).
- [4] Li, Z., Levin, D., Spring, N. and Bhattacharjee, B.: Internet Anycast: Performance, Problems, & Potential, Proc. of the 2018 Conference of the ACM Special Interest Group on Data Communication (SIGCOMM '18), New York, NY, USA, Association for Computing Machinery, pp.59–73 (online), DOI: 10.1145/3230543.3230547 (2018).
- [5] Savage, S., Collins, A., Hoffman, E., Snell, J. and Anderson, T.: The End-to-End Effects of Internet Path Selection, Proc. of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM '99), New York, NY, USA, Association for Computing Machinery, pp.289–299 (online), DOI: 10.1145/316188.316233 (1999).
- [6] Xiao, L., Lui, K.-S., Wang, J. and Nahrstedt, K.: QoS extension to BGP, 10th IEEE International Conference on Network Protocols, 2002. Proceedings., pp.100–109 (online), DOI: 10.1109/ICNP.2002.1181390 (2002).
- [7] Egilmez, H. E. and Tekalp, A. M.: Distributed QoS Architectures for Multimedia Streaming Over Software Defined Networks, IEEE Trans. on Multimedia, Vol.16, No.6, pp.1597–1609 (online), DOI: 10.1109/TMM.2014.2325791 (2014).
- [8] obinata: eSports時代のISPを考える：Troubleshooting Gaming network connectivity, 〈https://www.janog.gr.jp/meeting/janog51/wp-content/uploads/2022/12/janog51-esports-obinata.pdf〉 (2023).
- [9] Liotou, E., Tsolkas, D. and Passas, N.: A roadmap on QoE metrics and models, 2016 23rd International Conference on Telecommunications (ICT), pp.1–5 (online), DOI: 10.1109/ICT.2016.7500363 (2016).
- [10] Tsolkas, D., Liotou, E., Passas, N. and Merakos, L.: A survey on parametric QoE estimation for popular services, Journal of Network and Computer Applications, Vol.77, pp.1–17 (online), DOI: 〈https://doi.org/10.1016/j.jnca.2016.10.016〉 (2017).
- [11] Filsfils, C., Previdi, S., Dawra, G., Aries, E. and Afanasiev, D.: Segment Routing Centralized BGP Egress Peer Engineering, RFC 9087 (2021).
- [12] Toyota, Y., Mishima, W., Kanaya, K. and Nakamura, O.: Performance Aware Egress Path Discovery for Content Provider with SRv6 Egress Peer Engineering, IEICE Trans. on Information and Systems, Vol.E106.D, No.5, pp.927–939 (online), DOI: 10.1587/transinf.2022NTP0003 (2023).
- [13] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and Shakir, R.: Segment Routing Architecture, RFC 8402 (2018).
- [14] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Li, Z.: Segment Routing over IPv6 (SRv6) Network Programming, RFC 8986 (2021).
- [15] Humble, J. and Farley, D.: Continuous delivery: reliable software releases through build, test, and deployment automation, Pearson Education (2010).
- [16] Faratin, P., Clark, D. D., Bauer, S. and Lehr, W.: Complexity of Internet interconnections: Technology, incentives and implications for policy (2007).
- [17] Jager, M.: Securing IXP connectivity, Proc. APNIC, pp.1–41 (2012).
- [18] Nakamura, R., Shimizu, K., Kamata, T. and Pelsser, C.: A First Measurement with BGP Egress Peer Engineering, International Conference on Passive and Active Network Measurement, Springer, pp.199–215 (2022).
- [19] Dawra, G., Talaulikar, K., Raszuk, R., Decraene, B., Zhuang, S. and Rabadan, J.: BGP Overlay Services Based on Segment Routing over IPv6 (SRv6), RFC 9252 (2022).
- [20] Faucheur, F. L., Clercq, J. D., Ooms, D. and Carugi, M.: BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN, RFC 4659 (2006).
- [21] Ford, A., Raiciu, C., Handley, M. J., Bonaventure, O. and Paasch, C.: TCP Extensions for Multipath Operation with Multiple Addresses, RFC 8684 (2020).
- [22] Habib, S., Qadir, J., Ali, A., Habib, D., Li, M. and Sathiaseelan, A.: The past, present, and future of transport-layer multipath, Journal of Network and Computer Applications, Vol.75, pp.236–258 (online), DOI: 〈https://doi.org/10.1016/j.jnca.2016.09.005〉 (2016).
- [23] Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Wischik, D. and Handley, M.: Improving Datacenter Performance and Robustness with Multipath TCP, Proc. of the ACM SIGCOMM 2011 Conference (SIGCOMM '11), New York, NY, USA, Association for Computing Machinery, pp.266–277 (online), DOI: 10.1145/2018436.2018467 (2011).
- [24] Chirwa, R. M. N. and Lauf, A. P.: Performance improvement of transmission in Unmanned Aerial Systems using multipath TCP, 2014 IEEE International Symposium on Signal Processing and Information Technology (ISSPIT), pp.000019–000024 (online), DOI: 10.1109/ISSPIT.2014.7300557 (2014).
- [25] Chao, L., Wu, C., Yoshinaga, T., Bao, W. and Ji, Y.: A Brief Review of Multipath TCP for Vehicular Networks, Sensors, Vol.21, No.8 (online), DOI: 10.3390/s21082793 (2021).
- [26] Łuczak, c. P., Ignaciuk, P. and Morawski, M.: Evaluating MPTCP Congestion Control Algorithms: Implications for Streaming in Open Internet, Future Internet, Vol.15, No.10 (online), DOI: 10.3390/fi15100328 (2023).
- [27] Paasch, C., Ferlin, S., Alay, O. and Bonaventure, O.: Experimental Evaluation of Multipath TCP Schedulers, Proc. of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop (CSWS '14), New York, NY, USA, Association for Computing Machinery, pp.27–32 (online), DOI: 10.1145/2630088.2631977 (2014).
- [28] Ferlin, S., Alay, c., Mehani, O. and Boreli, R.: BLEST: Blocking estimation-based MPTCP scheduler for heterogeneous networks, 2016 IFIP Networking Conference (IFIP Networking) and Workshops, pp.431–439 (online), DOI: 10.1109/IFIPNetworking.2016.7497206 (2016).
- [29] Hinz, J.-T., Addanki, V., Györgyi, C., Jepsen, T. and Schmid, S.: TCP's Third Eye: Leveraging EBPF for Telemetry-Powered Congestion Control, Proc. of the 1st Workshop on EBPF and Kernel Extensions (eBPF '23), New York, NY, USA, Association for Computing Machinery, pp.1–7 (online), DOI: 10.1145/3609021.3609295 (2023).
- [30] Multipath-Tcp: Linux MPTCP Upstream Project, 〈https://github.com/multipath-tcp/mptcp_net-next/wiki〉. Accessed: 2023-11-19.
- [31] Multipath-Tcp: Linux MPTCP default scheduler code, 〈https://github.com/multipath-tcp/mptcp_net-next/blob/d2edcbba43b5b9b281e71265481a4498443a636a/net/mptcp/protocol.c#L1449-L1459〉. Accessed: 2024-02-03.
- [32] Biederman, E. W. and Networx, L.: Multiple instances of the global linux namespaces, Proc. of the Linux Symposium, Vol.1, No.1, Citeseer, pp.101–112 (2006).
- [33] Borkmann, D.: On getting tc classifier fully programmable with cls bpf, Proc. of netdev, Vol.1 (2016).
- [34] Debian iproute2 Team: ip-monitor(8) ― iproute2 ― Debian unstable ― Debian Manpages, 〈https://manpages.debian.org/unstable/iproute2/ip-monitor.8.en.html〉 (2012) (accessed: 2024-02-12).
- [35] ESnet: iperf3 Manual Page, 〈http://software.es.net/iperf/invoking.html#iperf3-manual-page〉 (accessed: 2023-11-19).
- [36] Yap, K.-K., Motiwala, M., Rahe, J., Padgett, S., Holliman, M., Baldus, G., Hines, M., Kim, T., Narayanan, A., Jain, A. et al.: Taking the edge off with espresso: Scale, reliability and programmability for global internet peering, Proc. of the Conference of the ACM Special Interest Group on Data Communication, pp.432–445 (2017).
- [37] Moubarak, M., Elbayoumy, A. D. and Megahed, M. H.: Design and implementation of BGP novel control mechanism (BGP-NCM) based on network performance parameters, Ain Shams Engineering Journal, Vol.9, No.4, pp.2079–2091 (2018).
- [38] Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, S. and Dong, J.: Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering, RFC 9086 (2021).
- [39] Schlinker, B., Kim, H., Cui, T., Katz-Bassett, E., Madhyastha, H. V., Cunha, I., Quinn, J., Hasan, S., Lapukhov, P. and Zeng, H.: Engineering egress with edge fabric: Steering oceans of content to the world, Proc. of the Conference of the ACM Special Interest Group on Data Communication, pp.418–431 (2017).
- [40] Kanaya, K., Toyota, Y., Mishima, W., Shirokura, H. and Esaki, H.: Qoe-aware content oriented path optimization framework with egress peer engineering, 2022 Tenth International Symposium on Computing and Networking (CANDAR), IEEE, pp.36–45 (2022).
- [41] Habib, S., Qadir, J., Ali, A., Habib, D., Li, M. and Sathiaseelan, A.: The past, present, and future of transport-layer multipath, Journal of Network and Computer Applications, Vol.75, pp.236–258 (2016).
- [42] Xu, C., Zhao, J. and Muntean, G.-M.: Congestion control design for multipath transport protocols: A survey, IEEE communications surveys & tutorials, Vol.18, No.4, pp.2948–2969 (2016).
- [43] Liu, Y., Ma, Y., Coninck, Q. D., Bonaventure, O., Huitema, C. and K¨uhlewind, M.: Multipath Extension for QUIC, Internet-Draft draft-ietf-quic-multipath-06, Internet Engineering Task Force (2023). Work in Progress.
- [44] Amend, M., Brunstrom, A., Kassler, A., Rakocevic, V. and Johnson, S.: DCCP Extensions for Multipath Operation with Multiple Addresses, Internet-Draft draft-ietf-tsvwgmultipath-dccp-11, Internet Engineering Task Force (2023). Work in Progress.
- [45] Nikravesh, A., Guo, Y., Qian, F., Mao, Z. M. and Sen, S.: An in-depth understanding of multipath TCP on mobile devices: Measurement and system design, Proc. of the 22nd Annual International Conference on Mobile Computing and Networking, pp.189–201 (2016).
- [46] Hurtig, P., Grinnemo, K.-J., Brunstrom, A., Ferlin, S., Alay, Ö. and Kuhn, N.: Low-latency scheduling in MPTCP, IEEE/ACM Transactions on Networking, Vol.27, No.1, pp.302–315 (2018).
- [47] Viernickel, T., Froemmgen, A., Rizk, A., Koldehofe, B. and Steinmetz, R.: Multipath QUIC: A deployable multipath transport protocol, 2018 IEEE International Conference on Communications (ICC), IEEE, pp.1–7 (2018).
- [48] 金子直矢，伊東孝紘，勝田 肇，渡辺敏暢，阿部 博，大西亮吉ほか：複数回線を冗長併用する通信技術のWebRTC映像伝送への適用と評価，情報処理学会論文誌デジタルプラクティス（TDP），Vol.3, No.3, pp.21–31 (2022).
- [49] Zheng, Z., Ma, Y., Liu, Y., Yang, F., Li, Z., Zhang, Y., Zhang, J., Shi, W., Chen, W., Li, D. et al.: Xlink: Qoe-driven multipath quic transport in large-scale video services, Proc. of the 2021 ACM SIGCOMM 2021 Conference, pp.418–432 (2021).
- [50] Barakabitze, A. A., Mkwawa, I.-H., Sun, L. and Ifeachor, E.: QualitySDN: Improving video quality using MPTCP and segment routing in SDN/NFV, 2018 4th IEEE Conference on Network Softwarization and Workshops (NetSoft), IEEE, pp.182–186 (2018).
- [51] Yang, F., Amer, P. and Ekiz, N.: A scheduler for multipath TCP, 2013 22nd International Conference on Computer Communication and Networks (ICCCN), IEEE, pp.1–7 (2013).
- [52] Cao, Y., Xu, M. and Fu, X.: Delay-based congestion control for multipath TCP, 2012 20th IEEE International Conference on Network Protocols (ICNP), pp.1–10 (online), DOI: 10.1109/ICNP.2012.6459978 (2012).
- [53] Lim, Y.-s., Nahum, E. M., Towsley, D. and Gibbens, R. J.: ECF: An MPTCP Path Scheduler to Manage Heterogeneous Paths, Proc. of the 13th International Conference on Emerging Networking EXperiments and Technologies, CoNEXT '17, New York, NY, USA, Association for Computing Machinery, p.147–159 (online), DOI: 10.1145/3143361.3143376 (2017).
- [54] 近藤優吉，カベンディッシュジルセウ，野林大起，池永全志：モバイルネットワークにおけるビデオストリーミングのためのMPTCPスケジューラの性能評価，電子情報通信学会技術研究報告．IA，インターネットアーキテクチャ，Vol.121, No.68, pp.62–67（オンライン），入手先〈https://cir.nii.ac.jp/crid/1050571859119409024〉 (2021).
- [55] Corbillon, X., Aparicio-Pardo, R., Kuhn, N., Texier, G. and Simon, G.: Cross-Layer Scheduler for Video Streaming over MPTCP, Proceedings of the 7th International Conference on Multimedia Systems, MMSys '16, New York, NY, USA, Association for Computing Machinery, (online), DOI: 10.1145/2910017.2910594 (2016).
- [56] Xing, Y., Xue, K., Zhang, Y., Han, J., Li, J., Liu, J. and Li, R.: A Low-Latency MPTCP Scheduler for Live Video Streaming in Mobile Networks, IEEE Trans. on Wireless Communications, Vol.20, No.11, pp.7230–7242 (online), DOI: 10.1109/TWC.2021.3081498 (2021).
- [57] Wei, W., Han, J., Xing, Y., Xue, K., Liu, J. and Zhuang, R.: MP-VR: An MPTCP-Based Adaptive Streaming Framework for 360-degree Virtual Reality Videos, ICC 2021 - IEEE International Conference on Communications, pp.1–6 (online), DOI: 10.1109/ICC42927.2021.9500817 (2021).
- [58] kernel development community, T.: Linux kernel docs BPF maps, 〈https://docs.kernel.org/bpf/maps.html〉. Accessed: 2024-02-03.
- [59] De Coninck, Q. and Bonaventure, O.: Multipath QUIC: Design and Evaluation, Proceedings of the 13th International Conference on Emerging Networking EXperiments and Technologies, CoNEXT '17, New York, NY, USA, Association for Computing Machinery, pp.160–166 (online), DOI: 10.1145/3143361.3143370 (2017).
脚注
- *1 ここでは出力先のVRFでその経路を利用したフォワーディングできるようにすることを指す．
- *2 以後，Egress Peer αから受信した経路はEgress Path αと表現する．
- *3 開発コミュニティのリポジトリ（https://github.com/multipath-tcp/mptcp_net-next）で公開されている．
- *4 FRRouting 9.0.1を利用．https://frrouting.org/
- *5 1988年に設立されたインターネット技術・標準・社会に関連する研究を行うコンソーシアム．
- *6 iperf 3.12を利用．https://iperf.fr/
- *7 Python 3.10.12および標準HTTPモジュール（https://docs.python.org/3/library/http.html）を利用．
- *8 ここでは，送信元IPアドレス，送信元ポート番号，宛先IPアドレス，宛先ポート番号，プロトコル番号を指す．
- *9 アプリケーションから見たスループット．
- *10 第4.2節で述べたようにEgress Pathが2系統存在する環境下では，（1）BGPベストパスを利用するデフォルトアドレスによるSubflow，（2）Transit A由来のEgress Pathのみを利用するSubflow，（3）Transit A由来のEgress Pathのみを利用するSubflowの最大3つを利用する．
- *11 CSP AS内のノードがすべて同一のL2SWで接続されている本トポロジにおいては，コンテンツサーバのルーティングテーブル上でBGPベストパスの変更が完了された状態と定義する．
- *12 移動通信サービスに係る無線局を自ら運用している事業者
- *13 iperf3 -P並列数のように実行することでデータ用TCPコネクションを並列化できる．
yas-nyan@sfc.wide.ad.jp
2020年 慶應義塾大学政策・メディア研究科修士課程修了．同年より同大学同研究科博士課程在学中．（株）ブロードバンドタワー所属．インターネット運用技術やSDNなどの研究に従事．WIDEプロジェクトボードメンバー．
w.mishima@ntt.com
2019年 北陸先端科学技術大学院大学修了．同年よりNTTコミュニケーションズ（株）に所属．SR技術をはじめとする経路制御，Streaming Telemetry・IPFIX等の監視技術の開発に従事．WIDEプロジェクトメンバー．
t-hayasaka@bbsakura.net
2021年 東北学院大学工学部卒業，2022年 よりBBSakura Networks（株）に所属．現在は同社でモバイルコアとデータプレーンのソフトウェア開発に従事．WIDEプロジェクトメンバー．
y.fukagawa@ntt.com
2022年 慶應義塾大学政策・メディア研究科修士課程修了．同年よりNTTコミュニケーションズ（株）に所属．高速ソフトウェアルータKamueeの研究・開発に従事．慶應義塾大学SFC研究所上席所員．WIDEプロジェクトメンバー．
1995年 電気通信大学電気通信学研究科情報工学大学院単位取得退学 修士，2003年 慶應義塾大学にて博士（政策・メディア）を取得．現在慶應義塾大学環境情報学部教授，インターネット移動体通信に関する研究に従事．IEEE，ACM各会員．WIDEプロジェクトボードメンバー．
osamu@wide.ad.jp
1990年 慶應義塾大学工学部数理工学科博士課程修了 博士（工学）．1993年 慶應義塾大学環境情報学部助手，大規模広域分散環境，インターネットの研究に従事．現在慶應義塾大学環境情報学部教授，慶應義塾CSIRTチーム長．ACM，ISOC各会員．WIDEプロジェクトボードメンバー．
採録日 2024年4月15日