RDPが通るようになった！！
パープー@4πR^2高負荷時RDPセッションが切断する
https://king.mineo.jp/question-answer/データ通信／音声通話 データ通信/38966
という検証をしたのですが、最近になってmineoでもRDPが切断されずに通るようになっています。つまり不具合改善されました。
接続後にセッションが切れることがなくなりました。また、バースト転送のために、RDPクライアントアプリケーションが通信速度を誤って高速と検知してしまい、高品質伝送に移行してしまって遅くなるという不具合も多少改善されています。ただしバースト転送は有効のため、帯域幅が1.5Mbpsしかないのに10～13Mbpsだと判定されてしまい、RDPセッション内で動画を再生すると切断されないもののフレームレートが低くなりカクカクになってしまいます。改善の余地はありそうです。（RDP検出したらバースト転送を一時無効化するとか）
おそらく法人契約が増えて、同様の不具合報告が続発したため対処したのだろうと思われます。
これからはSSHでトンネルしなくても直接接続できますよ。
次はIPv6対応もお願いします！！さすがに今の時代IPv4シングルスタックはちょっと時代遅れです。
4 件のコメント
コメントするには、ログインまたはメンバー登録（無料）が必要です。
特にシン・テレワークシステムがはかどるにゃ！
てか、あれやね、IPv6にmineoが対応したらYouTubeでアイナナとかすとぷりMV見たら、IPv6でアイナナのデータが(ry
>> あんちゃん@JR東日本実質出禁？ さん
1.5Mbpsでもそこそこ動きますから、スクロールを多用しなければ問題なくお仕事できるかと思います。動画系は紙芝居なので無理でしょうね。このあたり、ビットレートを適切に認識して、圧縮率が正しく調整されるようになれば、さらに実用的になっていくとは思いますけどね。IPv6対応だとYouTubeトラフィックは確かにv6側から流れてきますよねｗ＞おそらくオプテージ側のNAT動作に起因すると思われる。
確かにNATテーブルを常時保持するのはプロバイダーとしてはキツそうですね。
UDPと違ってTCPは再送手順があるのでフレームのパケットロスは基本発生しない。
覚えておきたいと思います。
>> Itedogawa さん
おそらくですがオプテージ側の動画制御がRDPが同じUDPなので、同様に処理されてしまっていたのだろうと思います。動画であればキャッシュで止まることなく帯域が節約できますが、データ転送が途中で強制的に止められてしまうとRDPには致命的になってしまっていました。一番簡単なのはYouTubeなどの動画データを配信元サーバーIPなど振り分け制御するようにしたのだろうと思います。さすがにパケットの中身まで検出するのは復号化しないと無理なのでやっていないでしょうし、法人向けのトラフィック傾向で中身を推定してAIで検出して制御するなんて高度なこともコストがかかりすぎてできないと思いますからね。