CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー ＞ 第174回 Protective ReRoute：サーバー側での経路変更による信頼性向上（パート2）」を公開しました
＃＃＃
はじめに
前回に続いて、2023年に公開された論文「Improving Network Availability with Protective ReRoute」に基づいて、Protective ReRoute（PRR）と呼ばれる、ネットワーク通信の信頼性を向上するGoogle独自の仕組みを紹介します。今回は、シミュレーションによるPRRの動作検証の結果を紹介します。
障害パターンによる復旧時間の違い
前回の記事で説明したように、PRRでは、TCPセッションに伴うOS上のネットワーク処理を利用して通信障害を検知して、パケットヘッダーに含まれるフローラベルを変更することで通信経路を切り替えます。TCPパケットの送信側では、送信パケットに対する受信応答（ACK）パケットをRTOで設定された時間内に受け取らない場合に、通信経路に障害が発生したと認識します。また、受信側から送信側に向けた経路（戻り経路）に障害がある場合は、受信側でも障害を検知する必要があります。この場合は、送信側が同じパケットを再送するので、受信側には、同じパケットを2回受信するPacket Duplicationのイベントが発生します。受信側はこのイベントによって、通信経路に障害が発生したことを認識します。このような送信側と受信側の処理の違いがあるため、障害の発生パターンによって、復旧に至るまでの処理の流れが変化します。図1は、2種類の具体例を示したものです。
この続きは以下をご覧ください
(リンク »)
はじめに
前回に続いて、2023年に公開された論文「Improving Network Availability with Protective ReRoute」に基づいて、Protective ReRoute（PRR）と呼ばれる、ネットワーク通信の信頼性を向上するGoogle独自の仕組みを紹介します。今回は、シミュレーションによるPRRの動作検証の結果を紹介します。
障害パターンによる復旧時間の違い
前回の記事で説明したように、PRRでは、TCPセッションに伴うOS上のネットワーク処理を利用して通信障害を検知して、パケットヘッダーに含まれるフローラベルを変更することで通信経路を切り替えます。TCPパケットの送信側では、送信パケットに対する受信応答（ACK）パケットをRTOで設定された時間内に受け取らない場合に、通信経路に障害が発生したと認識します。また、受信側から送信側に向けた経路（戻り経路）に障害がある場合は、受信側でも障害を検知する必要があります。この場合は、送信側が同じパケットを再送するので、受信側には、同じパケットを2回受信するPacket Duplicationのイベントが発生します。受信側はこのイベントによって、通信経路に障害が発生したことを認識します。このような送信側と受信側の処理の違いがあるため、障害の発生パターンによって、復旧に至るまでの処理の流れが変化します。図1は、2種類の具体例を示したものです。
この続きは以下をご覧ください
(リンク »)
本プレスリリースは発表元企業よりご投稿いただいた情報を掲載しております。
お問い合わせにつきましては発表元企業までお願いいたします。
お問い合わせにつきましては発表元企業までお願いいたします。
