今日は色々な人と電話・電話でした。最近のオンラインミーティングは顔を出さずに音声のやり取りが多いですよね。インターネットインフラがこの数十年で劇的な広帯域になったにも関わらず、こんなご時世で映像が乱れたり音声が途切れたり、混線状況になったり、数人での会話は若干トランシーバー的な対話をしなければならなかったりで、結局電話な優位性がまだまだ音声にはある模様ですね。あ、でも最近の音声SNSとか言われているClubhouseでしたっけ？私が傍から見ている分には、大昔のチャットルームが音声になったような感じですかね。ルームがどうとか言っているし。チャットにもオープンな部屋でROMな人が居たけど、Clubhouseもそんな感じに見えます。SNSは文字や情報を追いかけなくちゃいけないけど、Clubhouseだと聞き流し出来るからいいんですかね。なんかオンラインサロンとか怪しい系も益々増えてきそうですね。
さて、そうは言っても（高品質な）５Gが来てもギガ放題で垂れ流し放題でも来てくれれば良いのですが、携帯料金安くしろ～って言われている中で設備投資とのバランスも大変でしょうね…。コロナのワクチンが全国民に行き渡っても、誰でもインターネット最高状態で使い放題は来ないでしょう。
さて、そんな中でインフラ屋が今まで低帯域時代からどういった努力をしてきたかというと、帯域のコントロールです。20年前に私は1.5Mの専用線の帯域を64kの帯域の複数の拠点をVoIPをハンドリングするのにプロトコルやアプリケーションを判別した帯域制御を使いました(Packeteerというbulecoatに買収されて今はsymantec？もう形は残ってないかな？好きな製品でしたが）。帯域が混みあった場合は、何のパケットを優先に配送させるかが肝になってきます。帯域飽和している所でもどうしても大事なデータは優先してパスさせたいとかあるじゃないですか。その中の最優先事項は遅延を最小限にしたい音声です。でも今書いていてゾッとしますね。。。64kって（笑)まぁ中学生の頃に1200ボーで通信していた時代がほんとに懐かしいです。今は回線によっては８５０Mとかスピードテストでは出せますからねぇ。私の自宅は４５Mしかでませんけど・・・。
携帯電話も目の前の人と会話してもらえばわかりますが、遅延しています。1対１での会話では、人間の感覚の鈍さの許容がありましてなんとかなります。そんなもんで、SkypeからLINEやらと音声系アプリが台頭してきました。これらはジッターバッファリング技術が巧妙で、無料通話～ってことで流行ってきましたね。しかしそれも1対１ではのお話。多人数によるミーティングと映像を流し続けるとなると話は変わってきます。プロトコル的なお話は割愛しますが・・・
Skypeも複数人のミーティングが出来るツールだったのにいつのまにかzoomが台頭してきましたね。TEAMSがなんとか食らいついているかどうか・・・ですね。ちょっと前までは高級品なPolycomとか使っていたりしたのにね。
まぁ、今はただで使えるもので妥協していたり、機能的にファンクションが良かったりで人気の優劣があるみたいですね。zoomは人気が出た後はセキュリティの事故も酷かったですが、追い風強くその苦しい時期は耐えて成長しましたね。なので世の中が求めているものが出来れば良いだけじゃない・・・というニーズが上手く製品化できていたということでしょう。。。
でも、そのzoomやTEAMSであっても結構な帯域を食らいます。画面共有から色々機能も増えるしねぇ。P2Pの技術を可能な限り盛り込まれていても、インターネット環境問題の課題は中々克服できません。
音声やストリーミングはアプリケーションによるソフト努力と回線インフラによる努力とネットワーク機器による努力が必要な厄介なものです（更にWiFiもある）。インターネットでの音声の揺らぎやデータ損失（パケットロス）は高速道路の渋滞はなぜ起きるのかに近い話です。よく渋滞の話か水道管の話に例えたりします。
ただ、私自身はインターネット普及とともに広帯域化した事でQoSってあんまり使わなくなったんですよね。MPLSで気を使わねばと思うぐらいで、ベストエフォートな世界はギャランティ（帯域保障）がないので仮に帯域を想定しても時間帯によって上手くハマらない事が有ったり、逆にスループットを下げる要因になったりして使わなくなったんです。ただ、どうしても回線品質の課題はあったので、帯域活用系のアクセラレーション装置には興味はありました。そうこうしていたらSD-WANとか言われる時代になりましたね。
という事で、大昔からある帯域制御（QoS)や帯域アクセラレーションなお話が「いまでしょ？」という感じでしょうか。
いやぁ・・・前説長すぎですね・・・。
私の自宅はどの時間帯も大体同じパフォーマンスです。AM11時がちょっと辛いかなと思うぐらい。ダウンロードが４８Mでアップロードが１８Mぐらいです。ハイスピードなADSLという感じでしょうか。マンションなのでVDSL環境という事を考えればまぁ致し方ないです。５Gが来ても・・・４Gですら電波弱くてフェムトセル使っている位なので６Gまで待つしかないっす。
さて、この条件で、とりあえず提供する帯域を絞るとどうなるかやってみますかね。
U/D双方１０Mにセットしてみました。実際には最低帯域２５Mからなのでもったいない設定になりますが、これは制御が効いているかの確認です。
ガッチリ設定が効きましたね。ソフトウェア制御なのに処理がしっかり速くおこなわれておりますね。ちょっとぐらいはみ出るかなと思ったら逆に余裕で抑え込まれました。
もう一つ、優先制御も見てみましょう。
IPSec版では動かないと思っていたのですが、ちゃんと判定しております。なんでだろ。ダメ元での実験だったんですが・・・。
プライオリティを付けておりますが、あと一つ、帯域コントロールで重要なのがあります。それぞれにDelayが表示されているのもミソですよねぇ。
そして、プライオリティに対するギャランティです。
この帯域チューニングがねぇ・・・大変なんですよ。んだけど絶対品質を確保するにはベストエフォートの自由なフローでは駄目なんです。バーストトラフィックに負けちゃうんです。この匙加減をしっかりやってあげることが安定化の道でございます。
でも、弄る範囲はこれだけなので、ちょっとは楽になったのかもですね。
ということで、「広帯域だから(スループットもあるし)良い」という考えから、広帯域でもバーストに邪魔されないように「優先制御がだいじ」と思ってもいいころかもですね。SD-WAN系では当たり前なお話でしたが・・・。
スループットかアクセラレーションか・・・またこの戦いだ・・・orz
問題はこれをコンシューマーレベルでもオートマチックに出来れば良いんだけどね・・・（＾＾；
