一方向レイテンシ/ジッタ/パケットロスを測定する

ルートの輻輳とパケット損失が原因で遅延とStDevが増加していますが、フォワードパスとリバースパスが異なるネットワーク（例：init7.net、もう1つはhe.net）を経由するため、理解するのが非常に困難ですどのネットワークまたはホストが、輻輳、パケット損失、ジッター、および遅延の増加を引き起こしています。

フォワードとリバースmtrが正確な原因を特定できず、NOC @の連絡先が応答しないか、問題のパスで損失がないと主張した後、責任を絞り込む方法はありますか？（私はOpenBSDを使用しています。）

私はmtr、輻輳が発生している可能性がある2つのネットワークの両方の一部の顧客に直接実行してみましたが、特に、たとえばhe.netには多くのPOPがあり、しばしば特定の入口と出口POPの間で異なるルートが取得されるためmtr、ネットワークでパケットを失う可能性のある出口POPで直接ホスト（tservなど）にアクセスしようとすると、別のhe.netパスが到達するまったく同じPOPであり、パケット損失は発生しません。これは、何も問題がないことを証明します（一部のルートが実際に過負荷になり、他のルートが混雑しないようにする一方で、非顧客からのNOC @要求を無視する可能性があるという示唆以外）。

これを行う1つの方法は、UTCの真夜中からミリ秒単位のICMPタイムスタンプです。これには、両端を制御する必要がないという利点もあります。遠端がファイアウォールで保護されていない限り、機能する可能性は十分にあります。

ただし、信頼性の高い一方向測定を行うには、両端で確実に同じ時間を確保する必要があります。ICMPタイムスタンプは1ミリ秒の精度しかないため（多くのアプリケーションにはこれで十分ではありませんが、これには十分です）、ICMPタイムスタンプが有用なデータを提供する非協力ホストを見つけることはかなり簡単です。

両端を制御する場合は、NTPを1つのサーバーと同じサーバーのみに同期していることを確認してください。絶対クロックはそれほど重要ではありません。できるだけ同じ時間を体験することが重要です。

ICMPタイムスタンプが十分でない場合、両端を制御するときに測定を行うために、ruby / perl / pythonまたはCの10行を書くのは非常に簡単です。

ICMPタイムスタンプ測定を単方向で行うソフトウェアを実際に提案することはできません。hping2はICMPタイムスタンプの送信をサポートしていますが、何らかの理由で単方向の値を出力しません。私が書いたパッチを表示片道待ち時間にhping2のため。