問題タブ [congestion-control]

TCP 送信者の輻輳ウィンドウ サイズのグラフをプロットしようとしています。

私は次の例で作業しており、ns-3 の開発ブランチを使用しています。

http://intronetworks.cs.luc.edu/current/html/ns3.html

この例では、次の図に示すように、2 つのノード A と C が通過する単純な PointToPoint トポロジを実装します。

A ----------- B ---------------- C

10Mbps ------- 800Kbps

この例を実行すると、次のグラフが表示されます。

輻輳によってパケットがドロップされるため、典型的な cwnd のこぎり歯が見られると予想していました。

ここで何か不足していますか？

編集：

さらに調査すると、これは Ipv4AddressHelper によって配置された TrafficControl (1. を参照) が原因である可能性があります。src/internet/helper/ipv4-address-helper.cc の次のコード行をコメントすると、

この新しいグラフを取得します

この問題をさらに調査する必要があります。

1. ns-3 のトラフィック制御モジュールの設計と実装

私は RRTCC の初心者であり、RRTCC が受信メディアのビットレートをどのように調整するかを本当に理解していません。RRTCC の Internet Draft を読み込もうとしましたが、理解できません: https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-congestion-03

遅延と損失に基づいて推定帯域幅を計算します。次は何をするのでしょうか? 輻輳を制御するために送信レートを直接制御するにはどうすればよいですか?

私の質問は電気通信に関連していますが、ソフトスイッチを使用しているため、依然として純粋なプログラミングの課題です。

ゴール：

• コール ルーティング エンジンが使用するアルゴリズムを作成し、利用可能なリンク キャパシティを可能な限り高いレートで販売されるトラフィックで完全に飽和させます。

状況：

• 30 の音声チャネルの固定容量を持つ通信リンク (E1/T1) があります (1 チャネル = エンド ユーザー間の 1 つの音声通話なので、各リンクで最大 30 の同時通話を行うことができます)。
• リンクには毎月固定のランニング コストがかかるため、常にフルに活用するのが最適です (固定コストを分数で割った結果、利益が高くなります)。
• コール ルーティング エンジンにコールを送信することによって、リンク キャパシティを「争う」ユーザがいます。
• 各ユーザーは、特定の時間にランダムなリンク容量を消費できます。1 人のユーザーが一度にすべての容量を消費する可能性があります (つまり、ピーク時間)。ただし、オフピーク時間には容量を消費しません。
• 各ユーザーは、1 分あたりの通話料金が異なります
• 理想的な状況: 1 分あたりの通話率が最も高いユーザーによる通話で、リンクが完全に利用されています (24 時間 365 日)。

利用可能なコントロール:

• コール ルーティング エンジンは、コールを受け入れてこのリンクを使用して送信するか、コールを拒否できます

利用可能なデータ:

• 現在のリンクの使用状況
• 1 分あたりのユーザー レート
• ユーザーごとの 1 分あたりの最近の通話
• ユーザーの通話履歴 (アクセスにはコストがかかりますが、可能です)

例：

• ユーザー A のレートは 1 分あたり 1 セント、B は 0.8 セント、C は 0.7 セント
• ユーザー A の呼び出しを受け入れ、ユーザー A がリンク容量をすべて満たすことができる場合は、他のユーザーを拒否するのが最善です。
• しかし、通常、ユーザー A はリンク容量全体を埋めることができず、ギャップを埋めるために他のユーザーからの呼び出しを受け入れる必要があります
• 特定の瞬間にユーザーが送信する通話の数を制御できないため、どの通話を受け入れて何を拒否するかを計画するのは困難です

この問題に対するアイデアや提案されたアプローチはありますか?

ネットワークをランダムな時間オン/オフする実験を行っています。ネットワークを再びオンにするとすぐにパケット交換が開始されることを期待しています。ただし、オン期間でもパケットが交換されない一連の連続したオン期間とオフ期間が発生しています。

これは、TCP の輻輳制御の一部として実装された指数バックオフが原因であると思われます。おそらく、オフ期間とオン期間の期間は、次のタイムアウトがオフ期間中にあり、指数関数的な性質のために、次回は 2 倍になるように減少します。これは私の実験結果に影響を与えています。指数関数的バックオフの影響を取り除き、ネットワークが再び起動したらすぐにパケット交換を確認するために、どの Linux カーネル パラメータを変更できますか?

sshuttle は、 TCP-over-TCP メルトダウンという多くの議論された問題を解決すると主張しています。

sshuttle は、TCP ストリームをローカルで組み立て、ssh セッションでステートフルに多重化し、反対側で逆アセンブルしてパケットに戻します。したがって、TCP-over-TCP を実行することは決してありません。これは、安全な単なるデータオーバー TCP です。

しかし、プログラムの観点からは、ターゲット サーバーへの TCP 接続を、それに付随するすべて (読み取り指数タイムアウト) で維持します。SSH はまだudp. これは、TCP-over-TCP によく似ています。

ここでのトリックは何ですか？問題は本当に sshuttle によって解決されますか?

ソースコードを読んでみましたが、今のところ答えが見つかりません。

さらに重要なことは、彼らはどのようにそれを行うのでしょうか? ベアボーンでそれを再実装したい場合、どこからインスピレーションを探すべきですか?

質問

輻輳制御にトークン バケット アルゴリズムを使用するホスト マシンの場合、トークン バケットの容量は 1 メガバイトで、最大出力速度は 1 秒あたり 20 メガバイトです。トークンは、毎秒 10 メガバイトの速度で出力を維持する速度で到着します。トークン バケットは現在いっぱいで、マシンは 12 メガバイトのデータを送信する必要があります。データの送信に必要な最小時間は ____________ 秒です。

私のアプローチ

最初はトークン バケットがいっぱいです。空にする速度は (20-10) Mbps です。1 MB のトークン バケットを空にするのにかかる時間は 1/10、つまり 0.1 秒

しかし、答えは 1.2sec として与えられます。