DCCPの検証 (12)

LinuxのCCID実装の挙動について調査を行った。

無線LANアドホック1対1環境においてttcpで測定したところ、TCPでは24Mbps、CCID2では20Mbps、CCID3では16Mbpsという結果が出た。TCPではMACのキュー捨てが発生しているがDCCPではCCID2、CCID3ともに発生しない。CCID2ではTCPの輻輳制御を持っているという話であり、TCPと同じくキュー捨てが発生するものと期待していたが、期待通りではなかった。

VLCの伝送においては、CCID2ではかなりのノイズが見られたのに対して、CCID3ではかなり改善された環境で見ることが出来た。キュー関連の挙動についてはttcpと同じく、捨てが見られない。VLCによる実際の映像データの伝送では、ttcpで測定できた16Mbps以上のスループットのデータを出力できている。よってttcpの測定パラメータが間違っていたということか。

ともかく、CCID3はかなり良い、期待通りの結果であり、MAC送信キューの溢れを防ぐ手としてシェーピングとして本環境については期待された仕事を行っていることが確認できた。まだVLC側のアプリケーションバッファの振る舞いがUDPに近いものなので、それをTCP的に動作するようにしてVLCにおけるDCCPの仕事は終わることだろう。

この結果を踏まえて次の論点は、本当にスループットが落ちている場合に、最後の最後まで再送した方がいいのか(TCP)、それは捨てて再送を待つことなく、とりあえず持っている映像を再生したほうがいいのか(DCCP)ということになるかもしれない。

  1. ここにコメントするのが妥当かな。ポルトガル「出張」おつ。

    linphone DCCP出来ました。映像伝送もOK。dummynet使っていろいろやってみてるのだけど、実環境に近い設定ってどうすればいいんだろうね。遅延とかパケットロスとか帯域とか、そういうレビューってないのかしら。

    それはそうと、Decode As。やっぱりムリだったわ。UDP/TCPだとDecode AsでTransportが表示されたのだけど、DCCPだとNetworkまでだった。これも認識の違いかな。もちっと調べてみる。やっと「研究」が始まったはこれからはオリジナルワールドっすよ

    一通りやったら、Wireless環境でも検証したいのだけど、純粋なラボ環境が作れん。でも出来上がるともっと欲求増えてくるね。このテレビ電話をもっと高画質でやってみたいとか

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>