ViaviSolutions™ TrueSpeed による RFC 6349テスト - お客様 …...3 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

ViaviSolutions™TrueSpeed™によるRFC6349テスト-お客様のネットワークをお客様の立場で体験する

アプリケーションノート

RFC 6349は、ViaviがBell CanadaおよびDeutsche Telecomと共同で作成したTCPプロトコルの スループットの新しいテスト方法です。インターネット技術タスクフォース（IETF）が最近発行したRFC 6349は、ネットワークとサーバーのパフォーマンスを最適化するための体系的なプロセス、評価指標、ガイダンスを含む、TCPスループット解析を行うための再現可能なテスト方法です。

このアプリケーションノートは、RFC 6349の「TCPスループットテストのフレー ムワーク」の概要を説明したもので、今回Viavi MTS-6000Aマルチサービス アプリケーションモジュール（MSAM）およびMTS-5800ハンドヘルドネットワークテスターで利用可能となった、RFC 6349規格完全準拠の自動試験ツールのViavi実装版であるTrueSpeedについて重点的に解説しています。

このアプリケーションノートではまた、TrueSpeed RFC 6349とITU Y.1564 イーサネットサービスアクティベーション規格の統合についても説明しています。この画期的なテストの統合により、マルチサービス（トリプルプレイなど）環境でのユーザー体感品質を最適化する総合的な手段を提供します。

RFC 6349のTCPテスト手法RFC 6349は、ユーザー体感品質を評価するための優れた評価指標の提供を目的として、マネージドIPネットワークにおけるエンドツーエンドのTCP スループット測定のための実践的な方法を規定しています。RFC 6349フレームワークでは、TCPスループットを最適化するためのTCPとIPのパラメータについても規定しています。

RFC 6349は、TCPテストを実施する前に、必ずレイヤ2/3の開通試験を実施するように推奨しています。レイヤ2/3でネットワークを検証した後、以下の 3つのテストステップを行うように規定しています。

 y パスMTUの検出（RFC 4821に基づく）によりネットワークの最大伝送単位（MTU）を検証し、アクティブなTCPセグメントサイズテストでTCPペイロードが断片化されていないことを検証。

 y 往復遅延と帯域幅のベースライン測定によりTCP帯域遅延積（BDP）を自動的に計算し最適TCPウィンドウサイズを予測。

 y 単一・複数のTCP接続スループットテストで予測TCPウィンドウサイズを検証することで「フル帯域」TCPテストの自動化が可能。

以下のサブセクションでは、各RFC 6349のテスト手順の詳細を解説してい ます。

2 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

RFC 6349に規定されているように、帯域遅延積（BDP）は最適化されたTCPウィンドウで、以下のように算出されます。

この例では、BDPは140kBとなります。これは、送信者の64kBウィンドウの 2倍以上のサイズであるため、送信者は約20Mbpsスループットを達成するだけです。

RFC 6349は、RTTを測定する以下のようなメカニズムを定義しています。

 y レ イ ヤ 2 / 3 で ア ク テ ィ ブ な ト ラ フ ィ ッ ク を 生 成 し 、 一端から他端に「ループバック」する

 y パケットキャプチャ

 y ネットワークデバイスからのMIB情報（RFC 4898）

y ICMP ping

BDPはRTTとBBの両方に依存しているため、BBの測定も必要です。RFC  2544などのレイヤ2/3テストは、運用ネットワークに採用され、BBを測定する手段の1つとして規定されています。RTTとBBの両方が取得されると、RFC 6349により、その後のTCPスループットテストの予測TCPパフォーマンスの計算を実行できるようになります。

単一・複数のTCP接続スループットテスト

TCP接続テストの接続本数を1つまたは複数のどちらにするかは、エンド ユーザー環境で設定されているTCP RWNDとそれに関係するBDPのサイズに 依存します。例えばロングファットネットワーク（LFN）のBDPが2MBの場合、このネットワークパスは複数接続でテストするほうがより現実的です。標準的なホストTCP RWNDサイズが64kBの場合は（Windows XPなど）、32本のTCP接続本数で小規模オフィスのシナリオがエミュレートされます。

複数接続テストはRFC 6349では要求されていませんが、TCPスループットを正確に検証するためのより現実的な手段として強くお勧めします。RFC 6349は、TCPスループットテスト時に測定する評価指標も具体的に定義していますが、これについては後ほど説明します。

RFC 6349の評価指標以下では、RFC 6349のTCP評価指標と、それら指標を使用したTCPパフォーマンス劣化原因の診断に関する例を取り上げます。

TCP転送時間

最初のRFC 6349評価指標はTCP転送時間です。これは、単に同時TCP接続 でデータブロックの転送にかかる時間の測定です。理想的なTCP転送時間は、ネットワークパスBBとネットワークパスに関連する各種レイヤ1/2/3オー バーヘッドに依存します。たとえば、500MbsのEthernetサービスでの5つの 同時TCP接続で100MBをまとめて転送すると、各接続は100MBずつアップ ロードします。テスト中、各接続のスループットは異なることがあるため、 全体的なスループットレートの判定は必ずしも容易ではなく、特に接続数が増加すると難しくなります。

パスMTUディスカバリ（RFC 4821準拠）

TCP実装では、パスMTUを学習するためにインターネット制御メッセージプロトコル（ICMP）の「断片化要求」メッセージによるパスMTUディスカバリ テクニック（PMTUD）を使用します。IPヘッダセットに「断片化なし」（DF：don’t fragment）ビットを送信するパケットがデバイスにあり、そのパケットが次のホップのMTUより大きい場合、パケットはドロップされ、デバイスはパケ ットを生成したホストに「ICMP断片化要（ICMP  need  to  frag）」メッセージ を返信します。「ICMP断片化要」メッセージには次のホップのMTUが含ま れ、PMTUDはこれを使用して自己調整します。残念ながら、ネットワーク マネージャの多くはICMPを完全に無効にしているため、このテクニックはいくぶん信頼性に欠けます。

このためRFC 6349は、ネットワークパスMTUを検証するために、RFC 4821 に従って、パケット化レイヤパスMTUディスカバリ（PLPMTUD）を実行する ことを提案しています。つまり、PLPMTUDでは、ライブTCPトラフィックを使 用してMTU用にネットワークを「ポーリング」することを規定しています。 IPパケットのDFビット設定と同じテクニックが実装されていますが、これはライブTCPセッションを使用するため、ICMPに依存しませんこのアルゴリズム は、MTUの検索にTCPの再送条件を使用します（この後のどの試験手順でも断片化が発生しないようにするため）。

ベースライン往復遅延と帯域幅

TCPテストの開始前に、ベースライン往復時間（RTT）、すなわち輻輳の無い状態における固有遅延とエンドツーエンドネットワークのボトルネック帯域幅（BB）を判定することが重要です。これらのベースライン測定は、帯域遅延積（BDP）の計算に使用されるとともに、この後のテスト手順で使用される、TCP受信ウィンドウ（RWND）および送信ソケットバッファのサイズの見積りに使用されます。

広域ネットワーク（WAN）リンクでは、受信者からACKを受信する前に送信者が伝送可能なバイト数を調整するようTCPを適切に設定する必要があります。この「伝送中」のバイト数は、通常TCPウィンドウと呼ばれますが、実際はいくつかのTCPウィンドウメカニズムが作動しています。

図1は、25ミリ秒の往復遅延（RTD）を伴う45Mbps  WANリンク上でのデータバイトのTCP伝送の概念図です。

発信側（ウィンドウ＝64kB） 64 kB

受信側ACK

45Mbpsリンク（往復遅延25ms）

発信側へのACK到達時間12.5msストップ送信

インターネット

図1. 25ミリ秒の往復遅延（RTD）での45Mbps WANリンク上でTCP伝送中の データバイトの概念

図1では、TCPウィンドウが正しく微調整されておらず、ACKを要求する前に 送信者から64kBしか送信されません。

BDP=リンクボトルネック帯域幅（BB） × 往復時間（RTD）

8 

3 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

理想的なTCP転送時間は約8秒ですが、この例では実際のTCP転送時間は 12秒でした。TCP転送指標は12÷8=1.5であり、接続全体の転送には、理想値より1.5倍かかったことを示しています。

TCPの効率性

TCP再送は、どのようなTCP/IPネットワーク通信でも起きる現象です。パフォーマンスに支障を来す再送信数の判断は、数値のみからは困難です。RFC  6349では、ペイロードの再送信のために使用されたネットワーク転送の相対的な割合を把握できるよう新しい評価指標が定義されています。

これはTCPの効率性評価指標、つまり再送信されなかったバイトの割合で、以下のように定義されています。

RFC 6349TCP調整ガイドラインTCPパフォーマンスが期待に満たない場合のために、RFC 6349では考えられる原因についてのガイドラインを提供しています。

 y 中間ネットワークデバイスは、TCP接続を積極的に再発生させ、TCP  RWNDサイズ、MTUおよびその他の要素を変える場合があります。

 y シェーピングの代わりにポリシングによりレートが制限されると、テイルドロップのために過剰なTCPが再送される原因となります。

 y 最大TCPバッファスペース すべてのオペレーティングシステムは、TCP接続で使用されるシステムメモリ量を制限するグローバルメカニズムを備えています。一部のシステムでは、 それぞれの接続に入力データ、出力データおよび制御に使用される総メモリに 適用されるメモリ制限があります。その他のシステムでは、接続あたりの入出力 バッファスペースの個々に制限が存在します。クライアント/サーバーのIPホストは、高パフォーマンスネットワークには小さすぎる最大TCPバッファスペース制限を用いて設定されることがあります。

 y ソケットバッファサイズ 大半のオペレーティングシステムは、接続ごとの送受信バッファ制限をサポートしており、これは最大メモリ制限内で調整可能です。これらのソケットバッファ は、TCPバイトとオーバーヘッドのフルBDPを保持するのに十分な大きさでなければなりません。ソケットバッファサイズを調整するにはいくつかの方法がありますが、TCP自動調整は、TCPパフォーマンスとメモリ使用状況のバランスが最適になるよう自動的に調整します。

ネットワーク/ホスト問題と推奨ソリューションの全リストは、RFC 6349を 参照してください。

ViaviによるRFC 6349の実装Viaviは、RFC 6349テスト方法をMTS-5800およびMTS-6000A MSAM EthernetアナライザTrueSpeedに組み込み、業界で初めて完全自動のRFC 6349を実装しました。TrueSpeedは、テスト構成ファイルの採用により、技術者がテスト構成を読み込むだけですむようになっており、技術者がGoを押すだけでテスト結果レポートが発行されます。

図2は、Viavi TrueSpeedテスト機能を用いたシナリオを示しています。

送信バイト数－再送信バイト数

送信バイト数 x100

送信バイト数は、最初に送信されたバイト数と再送信バイト数を含む送信された合計TCPペイロードバイト数です。この評価指標は、トラフィック 管理、輻輳回避、およびRenoやVegasといった各種のTCP実装など、さまざま なサービス品質（QoS）機能間での比較を提供します。

例えば、100,000バイトが送信され、2,000バイトが再送信されなければならなかった場合、TCPの効率性は次のように計算されます。

102,000–2,000

102,000x100=98.03%

TCPの再送方法はパケット損失の分布により影響が異なるため、レイヤ2/3でのパケット損失率は、再送率に直接相関しないことに留意してください。

バッファ遅延率

RFC6349ではバッファ遅延率も定義していますが、これはTCPスループットテスト中のベースラインRTTからのRTTの増加率で、輻輳のない状態での ネットワークパス固有のRTTです。

バッファ遅延率は次のように定義されます。

例えば、ベースラインRTTパスが25msであり、平均的なTCP転送中のRTTが32msに増加するネットワークのバッファ遅延率は次の式で計算できます。

つまり、TCP転送中にRTD（輻輳）28%の増加が起こり、これによりTCP全体のスループット低下が誘発され、エンドユーザがより長い遅延を経験することになります。

転送中の平均RTT－ベースラインRTT

ベースラインRTT x100

x100=28%32–25

25 MTS-5800 TCPクライアント

325Mbps、6ms RTT

MTS-6000A TCPサーバー

図2. TrueSpeedスループットテストのテストシナリオ

4 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

これは、お客様の認定情報レート（CIR）が325Mbps、RTTが約6ミリ秒、BDPが約250kBでのLFNです。この例では、MTS-5800は、TCPサーバーであるMTS-6000AにスループットテストをアップロードするTCPクライアントとしての役目を果たしています。

テストは推奨デフォルト設定で自動的に実行され、平均3分後に完了します。テストステップごとに結果がグラフ表示されます。

テストはRFC  6349に規定されている順に実行され、パスMTUテストが最初 に実行されます。図11に、パスMTU1500バイトのネットワーク例を用いた このテストの結果を示します。

TrueSpeedテストには次の2つのワークフローがあります。

 y インストールテストモード：ユーザーはアドレスとCIR値を入力する必要があるだけです。MTSはRFC 6349に従ってすべてのTCPパラメータを自動入力します。

 y トラブルシューティングテストモード：上級ユーザーはTCPテストの多くの側面を制御して、高度なトラフィックシェービングテストをはじめとする集中解析を実行できます。

以下のトピックは2つの異なるテストモードの概要を示すものです。

インストールテストモード

このモードでは、技術者が新規のエンドカスタマーサービスのプロビジョニング/インストールに派遣され、RFC  2544またはY.1564レイヤ2/3テストを まず実行します。次に、すべて同じMTSアドレス情報（IPアドレス、VLAN、QoS など）を使用して、自動TrueSpeedインストールテストを行います。

リモートMTSはIPアドレスを使って設定されており、すべてのテストはローカルMTSから行われます（1人によるRFC  6349テスト）。以下にテストシーケンスの概要を示します。

技術者がCIRとテスト時間を入力します。

y MTS（MTSフィールドテスタ）がTCPウィンドウサイズと接続数に関するすべてのフィールドに自動入力します。

y MTSは、ローカル装置からアップロードに続いてダウンロード（スピードテスト）を実行します。

 y 簡単な合否結果とレポートをローカルMTS（MTSフィールドテスタ）に報告します。

以下に、MTS（MTSフィールドテスタ）の参考画面と共にステップバイステップのより詳細なガイドを示します。

1.   技術者はローカルとリモートMTS（MTSフィールドテスタ）用のIPアドレスを設定します。レイヤ3接続を検証するためのpingも発行できます。 ローカルMTS（MTSフィールドテスタ）はリモートMTS（MTSフィールドテスタ）に接続し、TCPポート3000を使用してすべてのテストの設定と結果の取得を行います。

図3. IPアドレスの設定

2.  技術者は、以下に示すように、1つの画面でレイヤ4SLAテストを行うための設定をします。

図4. SLAテストの設定

1.  全TCPテスト用の合計テスト時間（最短30秒）。2.  ローカルとリモートのQoS/VLAN設定（VLANは非表示）。3.  テストするサービスのレイヤ1/2のCIR。

複雑なTCPウィンドウサイズや接続数の設定はありません。MTS（MTS フィールドテスタ）はRFC 6349を使用して自動的にそれらの値を算出します。

3.  技術者は「テストを実行（Run Test）」をクリックします。

ローカルMTS（MTSフィールドテスタ）がアップストリームとダウンスト リームの両方向のRFC 6349テストを自動的に実行します（スピードテストのよ うに順次実行）。

図5. RFC 6349テストの実行

5 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

前述の通り、TCPスループットテストはCIRウィンドウサイズ（Walk-the-Windowシリーズの4番目）で行われ、より時間をかけた詳細なテストを提供します。

テストが完了すると、簡単な合否決定（図8）と詳細なスループットテスト 結果画面（図9）が表示されます。この例では、テストは40Mbpsポリサーの ためにアップストリーム方向で不合格となっています。この状況では、お客様 の実際のスループットは12.3Mbpsになります。さらに、TCP効率とバッファ遅 延評価指標は、低いTCPパフォーマンスの原因の診断に役立ちます。この例 では、ポリサーによりパケットがドロップされています。

RFC  6349に基いて、以下に概説するテストが行われます。このテストの詳細説明は、下記の「トラブルシューティングテストモード」のトピックを参照してください。

 y パスMTUの検出（RFC  4821に基づく）  - アクティブTCPセグメントサイズテストでネットワークMTUを検証し、TCPペイロードが断片化しないようにします。

y RTTテスト  -  サービスのRTTを測定し、TCPのBDPを自動計算するために最適なTCPウィンドウサイズを予測します。

y Walk-the-Window  -  4つの異なるTCPウィンドウサイズテストを行い、スループットをレイヤ4CIRの25%から100%に上げます。

y TCPスループット - CIRでのより詳細なスループットテストを行い、合否決定、 RFC 6349評価指標、および詳細グラフを提供します。

Walk-the-Windowテスト結果が表示され、結果の横のボックスをクリックするとアクセスできます。

各テストにはアップストリームとダウンストリームのボタンがあります。この例では、アップストリームに40Mbpsポリサーがあり、すべてのウィンドウ設定で顕著なパフォーマンス上の問題がありました。CIRウィンドウ設定は常に4番目にテストするウィンドウで、この例での結果は40Mbpsであるべきでした。

図6. Walk-the-Windowテスト画面 - アップストリーム

図7では、ダウンストリーム方向にはポリサーはなく、スループットは4番目のウィンドウサイズ（CIRウィンドウサイズに等しい）をはじめとして、すべてのケースで理想値を満たしています。

図7. Walk-the-Windowテスト画面 - ダウンストリーム 

 図8. 合否テスト結果

図9. 詳細なTCPスループットテスト結果

テストの完了後、グラフ表示のテストレポートが出力され、テスト設定も 保存できます。

6 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

トラブルシューティングテストモード

このモードでは、ユーザーはテスト設定を読み込むことも手動で設定することもできます。このモードは、上級の現場技術者にとって設定自由度が高く、より詳細なTCP理論の解説とRFC 6349結果に基づいてより詳細なテストシナリオを探求できます。

ユーザーはすべてのRFC 6349テスト手順を実行することも、図10に示すように一部のみ実行することもできます。この例では、CIRは325MbpsでRTTは6.5msです。

図10. TrueSpeedテスト構成の設定

テストは推奨デフォルト設定で自動的に実行され、平均3分後に完了します。テストステップごとに結果がグラフ表示されます。

テストはRFC  6349に規定されている順に実行され、パスMTUテストが最初に実行されます。図11に、パスMTU1500バイトのネットワーク例を用いたこのテストの結果を示します。

Walk-the-Windowテストは、ウィンドウサイズのテスト結果と期待される結果の特性に関する有益な情報を提供します。Walk-the-Windowテストは、パスMTUとRTTテストからのパラメーターを使用してウィンドウサイズスループットテストを行います。図13に、Walk-the-Windowテストの結果を示します。

図11. パスMTUテストの結果

パスMTUテストを完了した後、TrueSpeedはRTTテストに進みます。理想TCPウィンドウはBDPによって決まるため、これは重要です。BDPは、理想的なTCPスループットを予測するための以降のテスト手順で使用されます。

図12に、RTTが6.5msでのこの例のRTTテスト結果を示します。

図12. RTTテストの結果

図13. Walk-the-Windowテストの結果 

図13の例では、TCPウィンドウが256kBに設定されており、実際のTCPスループットは325MbpsのCIRを満たすだけです。多くの場合、エンドホストコンピューターは64kBなど、ずっと小さいウィンドウを使用するため、期待されるスループットよりずっと低い結果になります。ここでは、64kBウィンドウは80Mbpsまでしか達成していません。

次に、TCPスループットテストでは、問題のあるウィンドウサイズの詳細分析 が可能で、診断の補助としてRFC  6349評価指標結果が提供されます。 図14では、TCPウィンドウは384kBに拡大されており（サイズ128kBの接続を3つ使用）、これは325Mbps  CIRを大幅に上回っています。エンドカスタマーは 「ウィンドウが大きいほど良い」と考えて、この極端な設定に走りがちです。しかしながら、図14に示すとおり、このWAN環境では、ネットワークポリシングが325MbpsCIRでアクティベートされ、TCPパフォーマンスが著しく低下しています。

図14. TCPスループットテストの結果（基本的なビュー）

7 TrueSpeedによるRFC 6349テスト - お客様のネットワークをお客様の立場で体験する

ここで、TCP効率評価指標が96.87%で、バッファ遅延率が僅か0.54%であることは、バッファ遅延ではなく損失がパフォーマンスギャップの原因であることを示しています。図15では、スループットグラフをより詳細に検討します。

図15. TCPスループットテストのグラフ

ViaviはRFC 6349テストを拡張し、トラフィックシェーピングテストも提供しています。トラフィックシェーピングはインテリジェントネットワークバッファリングで、ネットワークデバイスがCIRに従ってトラフィックをシェーピングします。トラフィックシェーピングは、宅内機器（CPE）エッジデバイスで実行しますが、ネットワークプロバイダーがトラフィックをシェーピングすることもでき、これによりTCPパフォーマンスとエンドユーザー体感品質を大幅に向上させることができます。

高速回線から低速回線にダウンシフトする際にTCPトラフィックをシェーピングしないと、ネットワークポリシングによりTCPパフォーマンスに悪影響を与える可能性があります。シェーピングとは反対に、ポリシングはCIRを超えるトラフィックを切り落とすため、TCPの再送を引き起こし、エンドカスタマー のパフォーマンスが著しく低下します。図16に、トラフィックシェーパーと ポリサーの機能を比較します。

トラフィック

時間

トラフィック速度

トラフィック

時間

トラフィック速度ポリシング

トラフィック

時間

トラフィック速度

トラフィック

時間

トラフィック速度シェーピング

TrueSpeedは、ポリシングとの対比でシェーピングトラフィックを明確に示すトラフィックシェーピングの結果を提供します。図17はポリシングされているトラフィックを示していますが、これは4つのTCP接続間の帯域幅にギザギザが非常に多い分布となっています。

図17. TrueSpeedのトラフィックシェーピングの結果 （トラフィックがポリシングされている場合）

図18は、4つのTCP接続の間で帯域幅が均等に分布している場合の トラフィックシェーピングを示しています。

図18. TrueSpeedのトラフィックシェーピングの結果 （トラフィックがシェーピングされている）

TrueSpeedのRFC 6349とY.1564との統合ITUのY.1564はイーサネットサービスアクティベーションのITU規格です。

特長：

 y お客様のSLAを満たすための複数サービスのフィールド開通・パフォーマンス試験

 y 遠端でのループバックを使用したエンドツーエンドの自動マルチイーサネット/IPサービステスト

y LTE/4G IPサービスとトリプルプレイテストに最適

Y.1564で検出される問題には以下があります。

 y ネットワーク設定エラー - VLAN IDや優先度、IP TOS、最大スループット

 y 低サービス品質（QoS） - レイテンシー、ジッター、損失が大きい

 y 負荷状況下にある同一ネットワーク上でサービスがうまく機能していない

© 2017 Viavi Solutions Inc. この文書に記載されている製品仕様および内容は 予告なく変更されることがあります RFC 6349-an-tfs-ja 30179993 903 0714

〒163-1107東京都新宿区西新宿6-22-1新宿スクエアタワー7F

電 話：03-5339-6886ファックス：03-5339-6889Email: [email protected]

viavisolutions.jp

Y.1564はレイヤ2（イーサネット）とレイヤ3（IP）のパフォーマンスのみを検証 する規定であるため、TCPレイヤのテストは行われません。このため、Y.1564 で「合格」結果が出たとしても、エンドカスタマーのパフォーマンスは前の セクションで定義されているTCP関連のパフォーマンス上の問題が原因で低いことがあります。

このテストの欠点の解決策は、サービスアクティベーション時にTrueSpeed RFC 6349テストとY.1564を組み合わせることです。図19に、TrueSpeedをどのようにY.1564サービスパフォーマンステストと組み合わせられるかを示します。

図19では、音声とビデオサービスを一定ビットレートのUDPベースストリーム としてテストしています。これに対して、データサービスはTCPベースでバース ト性であるTrueSpeed  RFC  6349準拠トラフィックを使ってテストされます。 TCPアプリケーションのバースト性はネットワークQoSにストレスをかけ、 純粋なY.1564テストでは検出されない性能問題を引き起こす可能性があります。

期待されるTCPスループットが自動的に計算され、シンプルな合否結果が提

供されます。

図19. TrueSpeedサービスと組み合わされたY.1564パフォーマンステスト

この統合アプローチのViavi実装はSAMCompleteと呼ばれ、RFC 6349とY.1564を統合した業界唯一のサービスアクティベーション方法です。 SAMCompleteでは、TrueSpeedサービスが自動構成されます。ユーザーはCIRを指定するだけでよく、SAMCompleteがネットワーク状態に合わせて適切なTCPセッション数を自動設定します。この統合テストの終わりには、図20に示すように従来式のY.1564サービスと同様に、ユーザーはTrueSpeedサービスのシンプルな合否ステータスを受け取ります。

図20. TrueSpeedRFC 6349テストのシンプルな合否結果

結論このアプリケーションノートでは、RFC 6349に規定されているTCPのテスト方法を概説しました。これにより、ベストプラクティスに基づいてTCPスループットを順を追ってテストし、TCPテスト手法の違いによるばらつきを排除できます。RFC 6349で規定されているTCP評価指標は、ネットワーク問題（損失と遅延）の客観的な測定値を提供し、それらがTCPパフォーマンス全体にどのように影響するかを示します。

実際のTCPスループットが最適でない場合、RFC  6349はネットワークやエンドホストを調整するための実際的なガイドラインを提供します。

ViaviのTrueSpeedテストは完全自動のRFC  6349実装で、単純にボタンを押すだけであるため、経験のない技術者でも5分で実施できるとともに、上級のネットワークエンジニアがSLAの検証と実装に使用できる自動レポート作成機能も装備しています。