【考え中】最大配信速度を抑制したら余計に混雑する、図を描きました！
（5月25日 やはり間違えているかも、考え中です）
mineoの通信最適化の話です。この話うんざりな方は見ないでくださいね。
先日、下記のスレッドを立てました。
「【算数の話】最大配信速度を抑制したら余計に混雑する」
https://king.mineo.jp/my/sato/reports/35311
私の説明が悪くて、理解して頂けない方が多く居られたようです。
で、しつこくも、別の説明図を作ったので紹介します。
mineoでは、最適化の一つとして「最大配信速度を抑制」をしています。※
速度制限をすると、制限した速度以上に、余計に通信が混雑してしまいます。最大速度が低くなればなるほど、混雑が悪化します。
※詳細はこちら。原則、動画のみ対象、混雑時のみ実施。
https://king.mineo.jp/magazines/special/848
下は、（mineoではなく）全員が速度制限をされた場合の例です。
こんな例を作りました。
１秒に５箱ずつ通信できる回線があります。
(※1箱とは、例えば1Mbitなどのデータ量の事です)
毎秒、平均5箱ずつ通信データがやって来ます。
この時、最大１人１秒に１箱までしか運べない(1Mbps)、という速度制限が付いた場合、どうなるでしょうか。
■Ａ－１ 帯域制限が無い場合（１人５箱ずつ）
１秒目にAさんが５箱、２秒絵にBさんが、３秒目にCさんが５箱、、、と一人一定頻度で通信リクエストがある例です。
空いている帯域を占有できるので、１人５箱の通信が１人１秒で終わります。(1人5Mbps)
■Ａ－２ 帯域制限がある場合（１人５箱ずつ）
１秒間に１人１箱しか運べない速度制限が付いた場合。
５人で帯域を分けるので、全員１人５秒になります(１人1Mbps)。
この例では、一定頻度で一定数の通信をする為、常に帯域を５人で分け合っています。
この場合、制限前 1人５Mbps → 制限後 1人1Mbps
となり、帯域制限した割合だけ遅くなっています。
このイメージを持っている人が多いのでは？
ですが、実際の通信は、1人一定数の箱を運ぶ訳ではなく、沢山箱を運びたい人（大きいデータのダウンロード）、少ない箱を運ぶ人（文字だけのデータなど）色々な人が入り混じっています。
下はその例です。
■Ｂ－１ 帯域制限が無い場合（1人当たりの箱数が異なる場合）
下の図のDさんのように、箱１０個を運ぶ人が居たり、Gさんのように箱３個しか運ばない人が居たりします。
BさんとCさんのように二人同時に通信リクエストがあれば、２人で帯域を分け合うので、この時１人当たりの通信速度は5Mbpsの帯域の半分の2.5Mbpsになります。
ただしこの例は、１秒間に平均５個の通信で、Ａ－１やＡ－２と通信リクエスト数は変わりません。（図全体で55個）
この状態で1人１箱の速度制限が付いた場合どうなるでしょうか。
■Ｂ－２ 帯域制限がある場合（1人当たりの箱数が異なる場合）
注意：これはあり得ない図です！！
通信リクエスト通り箱を積んで行くと、帯域よりはみ出してしまいます。
1人辺りの箱数が異なるので、図A-2のように帯域を５人だけで分け合う事ができません。
帯域からはみ出した分は破棄されるのか？ いやいや、下の図のように、皆で帯域を分け合って速度を落として通信をします。
再度書きますが、１秒間に平均５個の通信で、Ａ－１やＡ－２と通信リクエスト数は変わりません。（図全体で55個）
■Ｂ－３ 帯域制限がある場合（1人当たりの箱数が異なる場合）
下の９秒目以降のように、帯域を６人、７人、と多い人数で分け合う事になります。
箱を水平に輪切りにして、切った部分を後で通信するよう先送りして行っているイメージです。
そうすると、細く長く通信する事になり、時間がかかります。つまり通信速度が落ちます。
1人１箱制限で速度が1/5になるかと思いきや、もっと遅くなってしまうのです。
つまり帯域制限をすると、混雑が余計に悪化する確率が上がるという事です。
このように混雑が悪化して行くと、バッファがあふれてパケット破棄やパケット再送が起き、そうなると更に混雑が悪化します。
再度書きますが、通信リクエスト数が多いせいではなく（図全体で55個）1人辺りが運ぶ箱数が異なるとこうなる場合があります。
特に大きいデータの通信が、仕掛中のまま長時間残っていると、後から来た通信の影響を受ける事になります。
この図を見て頂いて、「最大配信速度を抑制すると、余計に混雑する」という事を理解して頂けるでしょうか。
詳しい話は、下のスレッドに書いています。
「【算数の話】最大配信速度を抑制したら余計に混雑する」
https://king.mineo.jp/my/sato/reports/35311
興味ある方はご覧ください。
＞上のはバックオフアルゴリズムの問題点ですね
上とは、kanon好きさんの図の上側の事ですか？
大量データを流すとそちらが優先されてしまう現象が起こっているのですね？！
それは知りませんでした。びっくり。
＞トラフィックシェーパーはQoSまではいかないまでも、その絵の動きを目指すものですね(^^)
そうですか。そもそもそんな問題点があったとは！
VoLTEなどの音声通話が優先される、といった意味であれば、意味がわかります。
であれば、最適化という名目で、通信内容による優先度に優劣を付ける、事は常識とか当たり前、という事ではないですよね。
やっていないMVNOも多いですしね。
私も通信の知識は無いので間違っていたらすみません。
そんな素人がこんなスレを立ててすみません。
＞・単純に、「最適化」という処理時間が増える
「最適化」の処理時間も言われてみれば、確かに多少はあるでしょうね。
どの程度なのかよくわかりませんが、、、
＞・仮に「最適化」で回線が空いたとしても、「最適化」までの待ちは考慮してる？
これは１番目と同じ意味で待ちが発生するという意味でしょうか？
＞・受信バッファの先読み量減らす→動画が止まる確率が上がる→通信の向上する？
動画の視聴環境は間違いなく悪化しているんじゃないでしょうか。
（たぶんyoutube限定）
動画の抑制については、効果が出ているんじゃないかと私も推測しています。
＞運営の説明では一定の条件に当てはまる通信にのみ「通信の最適化」が適用されているという事だったように思います。
そうですね。動画を狙ってペーシングをしてるようです。
ですので、実際のmineoのペーシングそのもののイメージとは違います。
今朝、その事をスレ本文に追記しました。
ただ、動画でないのに動画と誤判定されている例もあるようで、悪影響がない訳ではないと思っています。
また少し前には、今よりずっと適用時間が長くて、体感スピードの著しい悪化が見られました。
今は体感上よくなっている気はしています。
ただペーシングを問題視している人が少ない気がしたので、スレッドを立ててみました。かなり前から構想しているたのですが、知識不足でなかなか書けず今頃になりました。
某は間延びと書いているので、間引きとは違います。
あくまでも間引きは画像データのみで、動画は間引けるわけがありません。
画質を劣化させる事は、ビットレートを変える事で実現していますが、それは表示側の装置の仕様に合わせて送信されているだけのことで、通信路上で途中で間引かれているわけではありません。
受け取り側の装置に合わせて、送り手側の装置がビットレートをコントロールしているだけて、途中で勝ってに出来るのは、水道の蛇口を絞って、流量を変えるだけの事です。
もしそんなことが動画と似たような大量データのやり取りを行っている他のアプリで行われたら、どうなるでしょう。正常な動作は保証出来なくなりますよね。
なので、絶対に動画データの部分部分を間引くなんてことは有りえない事です。
勿論通信途中で勝手に間引いている、というつもりで言っていたのではないのですが、言葉が違ったようですみません💦
ビットレート下げる＝動画の画質低下＝間引き
と結果的にユーザーが見る物は間引きされるている訳なので、そこは特に区別して書いていませんでした。
動画以外で速度制限しても動画のビットレート落とすような、データ量が減る効果は当然ありませんから、悪影響しかないと考えています。それが趣旨です。
> VoLTEなどの音声通話が優先される、といった意味であれば、意味が
> わかります。
> であれば、最適化という名目で、通信内容による優先度に優劣を付ける、
> 事は常識とか当たり前、という事ではないですよね。
> やっていないMVNOも多いですしね。
視点を MVNO管理内だけにするとそういう判断になるでしょうね。
ただ、網制御というのは MVNO範囲内だけで出来るわけでもないですし、キャリア側が「協定事業者(=MVNO)に対して混雑時・輻輳時などの制御を協力するように接続約款などで謳っている」(少なからず docomoはそれを書いています。他スレッドで私が言及しています)ので、MVNO管理外では何らかの制御がされるのも当然だと思っています。
実際に「借受帯域内しか速度が出ないように制御している」というのもある意味 MVNO帯域にはオーバーコミットを許さない訳ですから、MVNOの自網内で考えるのか、それとも POIから先へ出たパケットに関しても取り扱うのかを今一度整理していくのが良いと思います。
※今回の件を見ていると自網内だけではなく POIから先の制御も絡んでの
お話を若干でも考慮しないと「そもそも帯域制御が悪」と言う結論
ありきで話が進むだけだと思います。
帯域制御しなければならない理由はなにか？、なぜそのようなことを
しないとＮＧなのか？が、そもそも根本だと思います。
→MVNOビジネス上のコスト要因など主に管理面でのお話が主因である
ことは言うまでもなく自明だと思います。
> 動画以外で速度制限
mineoも識別できるであれば、動画以外は制限しないようにした方がクレームが少なくなることは分かっていると思いますよ。
でも、httpsでの通信の場合、ばななめろん さんが書かれているように「暗号通信の内容の検閲」に等しいことをしないと正確な識別ができないのです。代案として通信時の転送パターンによって「動画か否か？」という判定をせざる得ないかと。
これだと、誤判定は避けられないので少なくないケースで「動画では無いのに速度制限された。」という問題事象が発生していると理解しています。
> データ量が減る効果は当然ありませんから、悪影響しかない
データ量が増えるわけではないので、ちょっと視点を変えても良いかもしれません。
該当の通信の完了までの時間が延びることは明らかに該当ユーザにとって悪影響です。
ただ制限したことによって僅かでも良いので帯域が空くことにより、再送が減ったり、全体の通信のスループットが安定することが期待されます。
多数のユーザからランダムなタイミングで様々なサイズの送受信のリクエストが発生する通信回線で安定したスループットを出しながら帯域を100％使い切るのはかなり難しいです。少し空けたくらいにしないとうまく回りません。
私はそもそも混雑時間帯に「巨大なデータをMVNO回線を使って短時間で送受信したい」というニーズはミスマッチでは無いかと考えます。
限られた帯域リソースであることはあらかじめ分かっているのだから、お互い譲れるところは譲り合って現実的な使い方を見つけて行くしかないのだと思います。
さとさんのもともとの違和感は、当初のペーシングが17時半から24時までだったり、土日はお昼から23時までと長時間だったため、「高速通信できる時間帯までhttps通信を低速に抑制するペーシングは結果として混雑に拍車をかけているのでは？」というところから始まったのではないでしょうか？それが現在は実施時間帯が変更され、https通信をペーシングしなくても1Mbps以下しか出ないであろう「本当に混雑している時間帯のみ」に絞られましたので、もうペーシングによる悪影響はあまり気にしなくても良くなったのかもしれませんね。
＞「協定事業者(=MVNO)に対して混雑時・輻輳時などの制御を協力するように接続約款などで謳っている」
これは本当ですか？初めて知りました。
＞「そもそも帯域制御が悪」
とは全く思っていませんよ。ただ改悪になっているとしたらそれはやり方が悪いと思います。
意図的にやっているのではなく、やむなく起こった、というのは、理解しています。
ただ、mineo側で中身を判断が出来ないのであれば、効果が出ているか、悪影響を引き起こしているかの評価もmineo側では確認出来ない気もしますよね。
ですから、書いても良いと思うんですよ。むしろユーザーが声を上げないと何もわからないと思います。
＞ただ制限したことによって僅かでも良いので帯域が空くことにより、再送が減ったり、全体の通信のスループットが安定することが期待されます。
これは本当の話ですかね。スタッフブログの図を見ても、信じ難いのですが。
あの図によると、元々不公平であった（人によって通信速度が違った）所をペーシングにより公平にした図になっています。逆だと思うのですが。
ペーシングは特定の通信速度を制御するもので、いわば不公平を引き起こす物だと思います。
また制限すると、空いている帯域を使えない無駄が発生しますが、この無駄は安定化の為ですか？本当に？100Mbps出る所を1Mbpsに制限する必要あった？
その上、「混雑をより悪化」させる確率が上がる、というのが今回の趣旨です。
あと気持ち的な問題としては、楽天やフリーテルのようなスピードテストブーストをしているMVNOは嫌いだったのですが、mineoもそっち側に行ってしまった事に、かなり落胆しているというのはありますね。
時間帯を絞った時期から、確かに体感は良くなりました。
ただ、朝夕は1Mbps以下ではないですし、3Mbps目指しますなんて去年まで言っていましたよね。
個人的な感想では５月上旬に比べて中旬には、夕方の体感速度が良くなっている気がしています。
ですので、ユーザーの声を聞きながら調整をしている気がするんですよね。
そもそも設定内容の詳細を明らかにしていないし、詳細を変えても知らせてはくれていないですけどね。
スタッフブログには今も速度が遅いと書いている人が居たので、わかりませんが。
>朝夕は1Mbps以下ではないですし、3Mbps目指します>なんて去年まで言っていましたよね。
確かにそんなこと言ってましたね。
最近は下記のように目標が変わってしまいましたし、実際は、3つのアプリのうち2つはほぼ1Mbps以下のようです。（上図）
【運用目標】（夕方） ①3つのアプリの内、少なくとも1つは3.0Mbps以上
②3つのアプリの平均値で2.0.Mbps以上
https://king.mineo.jp/magazines/special/811
朝はもう少し良いのかな？
気まぐれトラベラー＠運営事務局 さんによると
・動画ペーシング適用対象の識別方法や、識別判定値を調整できるのか？
⇒最適化システムの技術仕様については、システム提供ベンダーの製品であるため、開示することができません。また、調整もできない仕様となっております。申し訳ございません。
との事です。
なので、ユーザーの体感等の情報を得てもアンコントローラブルな仕組みなようです。
NTT docomoの MVNO向け接続約款を見ると以下の記載があります。
●接続約款
https://www.nttdocomo.co.jp/binary/pdf/corporate/disclosure/interconnection/term/dsj_all.pdf
> 第８章 重要通信の取扱方法
>（相互接続通信及び他社相互接続通信の制限）
> 第46条
> ５ 当社及び協定事業者は、相互接続通信又は他社相互接続通信を
> 制限する場合には、協定事業者と協議の上定める保守確認事項により
> 協力するものとします。
重要通信(他に優先して接続する必要のあるもの)に関しての記載になりますが、きちんと『協定事業者と協議の上定める保守確認事項により協力するもの』と書かれています。
具体的な内容は２者間、または関係者間の NDAなどにより公表されていないものと思いますが、相互接続通信に関する制限の協力を挙げています。
> ただ改悪になっているとしたらそれはやり方が悪いと思います。
であるならば、きちんと帯域制御の功罪を整理して行かないと、結論ありきになりませんか？。
逆に「帯域制御しません」として、無限に借受帯域を増やすのか、または設備機器へ負荷を掛け続けるのが健全なネットワーク管理だとは思えません。
そういう視点はどの様に整理しているのか、表面上も読み取れないので指摘しています。
私は「不公平」というよりは「早い者勝ち」になってしまっており、後から来た人が必要以上に長時間待たされる、時にはタイムアウトになってしまう状態だったと理解しています。
例えるなら毎分100台の車がしか通れない道路に対して、混雑時は「毎分120台の車が通りたい」というリクエストが来ている状況かと。
その120台を全部通していたら、どんどん渋滞がひどくなってしまいます。
それを防ぐために120台の内、急ぎでは無い車（今回は画像の先行バッファリング分等）を制限して後回しにする対応に相当するのがペーシングかと。
> また制限すると、空いている帯域を使えない無駄が発生しますが、この無駄は安定化の為ですか？
「無駄」というよりは、通信機会の公平化のための「空」と考えていただくと良いと思います。
> 本当に？100Mbps出る所を1Mbpsに制限する必要あった？
1Mbpsという速度制限に関しては、私も疑問が残るところです。
全体の帯域の利用状況に応じて、柔軟に速度を変更できればより良いのですが、今回の装置はそこまでの対応はできていないと見ております。
> その上、「混雑をより悪化」させる確率が上がる、というのが今回の趣旨です。
ペーシング対象となる見込みのデータの割合やペーシングによって確保できる「空」に関して定量的な情報が無いので、何とも言えないところではありますが、ペーシング対象では無い通信を行うケースにおいては、「待ち時間が減る」と考えております。
通信帯域を出来るだけ使い切ることがベストだとするのであれば、リクエストキューを大きく取って、多少待たせるのも厭わない通信制御をおこなうことで実現に近づくことは可能だと考えますが、現状のように帯域キャパオーバーの状態でそんなことしたら、後から通信開始した人はいつまで経っても「繋がらない」という状況になりかねませんので、通信サービスとして「NG」だと考えます。
私は通信サービスの基本は「使いたい時に安定して繋がる」だと考えているので、速度に対する要求はあまり高くないのかもしれません。
スレ主はクレーマーで、
ｖｓ
コメント欄はmineoを擁護する人
みたいな戦いの構図になると大変辛いのですが、そういう戦いは望んでいないのをご理解下さい。
「mineoが悪い」「いや悪くない」みたいな言い争いを望んでいる訳ではないです。
あと最適化の文句を言うな、と思う人も多いと思いますが、そういう方はすみませんが見ないで閉じて頂きたいです。
＞甘栗大好き さん
＞なので、ユーザーの体感等の情報を得てもアンコントローラブルな仕組みなようです。
どこかでコメントしましたが、この手のDPI製品は製品の性能だけじゃなくノウハウが重要です。
そしてmineo（ケイ・オプティコム）にそのノウハウは無いと思っています。
なので、結局はベンダー任せにしかできず、自由にいじることは不可能なんだと思われます。
「どうやって動画と判定するか」なんて製品のキモだと思いますし簡単にベンダーが顧客に内容を喋らないと思います。どこから漏れるかわかりませんし。
だからこそ、この手の製品がベンダー任せでMVNOの設備に入れられること自体反対です。
企業であればその通信内容は社内でわかるのでトラブルになっても対応可能だと思いますが、通信事業者は通信するのは契約したユーザーなのでどんな通信をしているのかわかりません。
そして個別に対応できるほどのコストをかけられません。（料金的に）
この件ではおそらくベンダーがevilだと思っています。ケイオプはベンダーのセールスにうまく乗せられた・・・と。想像ですが。
＞朝はもう少し良いのかな？
1年ぐらい前は、朝のピーク(8:10付近)で8Mbps切るぐらい。（アプリAだと思って下さい）
> スレ主はクレーマーで、
> ｖｓ
> コメント欄はmineoを擁護する人
そんなつもりはないので、もしそう受け取られていたらすみません。
私は十分な告知をせずに最適化を導入したmineoを擁護するつもりは全く無いのです。
今回の装置の機能、性能やその効果に関しても懐疑的でもあります。
mineoは最適化の導入の前後における通信状況の変化に関して、定量的なデータを開示すべきとも考えております。
よって、さとさんが持たれている各種疑問点ももっともな部分が多いです。
だからこそ最適化の影響や功罪に関して私を含めたより多くの人がそれを正確に理解して、全体として良い方向に進めば良いと考えて、このスレに参加させていただいております。
evilがどう言う意味か分からない某でござる。w
お詳しそうなので教えて欲しいのですが、
＞「早い者勝ち」になってしまっており、後から来た人が必要以上に長時間待たされる、時にはタイムアウトになってしまう状態
こういう事は本当に起こっていりるのでしょうか？
帯域の優先度は、低速モードとプレミアムコースは別として、それ以外の人は全部同じだと考えていました。
pmakerさんが書かれているように、大きいリクエストをした人が優先されてしまうような現象って、ペーシング無し状態では常に発生しているのでしょうか？
こっちのスタッフブログでも質問しましたが、事務局からのコメントには回答がありませんでした。
https://king.mineo.jp/magazines/special/848/comments/137793?magazine_formatted_id=862
> 帯域の優先度は、低速モードとプレミアムコースは別として、それ以外の人は全部同じだと考えていました。
私は通信の専門家ではなく、実際にどのような機材でどのように通信制御しているかを存じている訳ではないので、正確ではない部分もありますが
私の理解だと一般ユーザの人に対するQoSは行われていないはずなので、通信リクエストに対する処理の優先度は同一のはずです。
帯域の優先度では無いところがポイントです。通信するデータ量はリクエストの処理が相手サーバに届いて処理が終わるまでは分からないケースも多いですし、そもそもベストエフォートですからお互いに帯域の最低保証などはないという理解です。
> pmakerさんが書かれているように、大きいリクエストをした人が優先されてしまうような現象って、ペーシング無し状態では常に発生しているのでしょうか？
原則としてリクエストが届いた順に処理されるので、もし先に大きなデータのリクエストが沢山あったら、その後のリクエストは待たされる時間が長くなると理解しています。
※リクエストあたりのデータのサイズには上限があるので、そこまでべらぼうなことにはならないはずですが、実際のデータ本体を受け取るまでにスマホ上のアプリとインターネット上のサーバとの間でのやり取りが何度かあるので、1回1秒待たされるだけでもすぐに5秒以上経ってしまうことが生じます。
動画アプリは、先読みのために割りと大きなデータのリクエストを最初の段階で複数回発行する処理を行っていて、そのリクエストがキューに先に入っているところに、後からリクエストをすることになり結果として長く待たされるので「非優先」と感じると思われます。
これを軽減するために動画のリクエストを判定して帯域を絞ることで、動画アプリ側のリクエストの発行を減らしてもらうというのがペーシングの狙いだと理解しています。※効果が出ていると思えないところもありますが、それは別の話なので。
もっとも現実の通信はもっとずっと複雑で使用するプロトコル、経由する通信路の特性、通信するアプリやサーバの影響もあるので制御する方々も苦労されていると思っています。
間違っている点があったら詳しい方ご指摘いただければ幸いです。
ベルりんさんの話を見る限り、プレミアムコース２週間前よりもhttps制限に引っ掛からなくなったという話もありますね。
https://king.mineo.jp/my/f535b538a3f7ed8d/reports/35463
私（プレミアムではない）の体感としても、夕方が良くなった印象です。
気のせいか偶然か何かわかりませんが。
「調整もできない」と言っていますが、どこまで、なのかはわかりませんね。
そもそもスピテスブーストしているので、スピテスが信用できないという話は置いておくとして。
去年夏からペーシングを始めて、段々と速度が落ちているのは、最適化の効果が出ていないか、単位当たりの帯域を落としているか、なんですかね。
先日の公取委宛資料では、最適化で原価を減らしているとか書いていたような気がしますが、、、
相互接続の件は、約款が難しくて意味があんまり理解できません…すみません。
「制限する場合」がどういう事を指しているのかよくわからなくて💦
＞と帯域制御の功罪を整理して行かないと、結論ありきになりませんか？
って何でしょうか。誰が何を整理するのですか。
実際mineoは、適用時間を減らしたり、チューニングを行っていると思われますが、それは何か問題があるから、その改善の為なのではないでしょうか。
＞そんなつもりはないので、もしそう受け取られていたらすみません。
いえいえ、別にしゅうさんがどうこう言う訳ではなく、単に人数比的に辛かっただけです。
通信の優先度の話に戻ります。
ペーシングなどの制御を何もしていない場合、
例えば、Windws Updateのような大きなファイルのダウンロードを、30分以上かけてしている人が居たとします。
午前11時台は、10Mbpsほどの速度で順調にすいすいダウンロード出来ていたのに、正午時過ぎたら人がどんどん遅くなり、1Mbps以下になって、のろのろダウンロードになって来た、
という感じで、通信の開始時間とは関係なく、その時点その時点の通信している人数で割った平等な速度でダウンロードするものだと思っていました。
「※リクエストあたりのデータのサイズには上限があるので、そこまでべらぼうなことにはならないはずですが」
と書かれていますが、上限は結構大きなサイズだという事ですね？
ここの図を見るとAさんが物凄く周りを圧迫しているので。
https://king.mineo.jp/upimages/view/magazine_section_image/225584/fullsize
この図のような現象は現実に発生しているという事ですね。
お礼言い忘れてた！時々降臨ありがとうございます
「リクエスト」というのは分割できない単位だったのですね。
その順番でキューに入るので、後から来た人は割り込み出来ないという事だったのですね。
この部分で皆さんと話が通じていなかった事に気付きました。
とすると、大きいデータをダウンロードする人は、頻回に小さいリクエストが分割して来るという図にしておかないといけなかったのですね。
ではここで疑問なのは、配信速度制限ですが、mineoの話では
「回線単位ではなく、各通信単位でかかります。」
という事なので、リクエスト単位でかかっているという意味なのでしょうかね。
>> と帯域制御の功罪を整理して行かないと、結論ありきになりませんか？
>
> って何でしょうか。誰が何を整理するのですか。
> 実際mineoは、適用時間を減らしたり、チューニングを行っていると
> 思われますが、それは何か問題があるから、その改善の為なのでは
> ないでしょうか。
帯域制御を行う意味もある訳です。
ネットワーク設備は常に負荷 100％で動作する前提にはなっていません。
電力供給の余裕率と一緒で常に「ある程度の余裕を残しておかないとならない」訳です。
そのためには「過剰な帯域を削ってでも余裕を生み出す必要がある」場合もあります。現状で言えば「大容量のデータを垂れ流すような転送要求を抑制する」事にあります。
ケイ・オプティコム側が帯域制御をしている現状は確かに「必要以上の帯域を使用されないようにする」事にもありますが、それ以上に「コンテンツが肥大化しすぎて、ネットワーク機器側の負荷に耐えられなくなってくるとトレンドで予測したのでは？」とも考えます。
ユーザー側からすればそれは管理側の都合かもしれませんが、サービス提供側からすれば「ユーザー都合よりも事業継続が優先」と考えているかもしれません。
見る側面によって価値判断基準がズレてくるので、それらも含めて「何を目的に帯域制御を行うに至ったのか？」の視点を考慮しないと結局「帯域制御は悪」とみられるのではないかと個人的には感じますが、いかがでしょうか？。
※本音を言えばユーザーなんてサービス事業者側の都合は知ったことでは
ないはずです。
同時にサービス事業者もユーザー側の都合に合わせる必要はないはず
です。
究極的には双方の都合に対して折り合いのつくところが重要で、
一方的にどちらが正しいというものでもないと考えています。
そもそもは「混雑時間帯にアクセス集中しているから制御する必要が出てきた」訳で、かつ根拠法の関係上「混雑してるからと言って接続要求を拒否できない」通信事業者の都合もあると考えるので、単に帯域制御だけに矮小化すると結論あり気になってしまうように思います。
帯域制御が上手く機能している前提なら、もちろんその話はアリだと思います。
お昼のパケロスは減っていないという話も聞きます。
それでも単位当たりの原価が減っているなら意味はあると思いますが、どうなんでしょうね。
あとはユーザーの体感がどうかもありますよね。
その「どうなんでしょう」の話を今しているつもりです。
しゅうさん「リクエスト」が分割できるかどうかの話ですが…
私は上の図のようなイメージを持っていました。
「リクエスト」はAファイル全体、Bファイル全体、のイメージでした。
それを細かい単位のパケットに分割して、複数のリクエストが同じ優先度で混じって流れているというイメージです。
パケットの単位が、もしもファイルサイズより大きい確率が高い、という事であれば、短いパケットと長いパケットが入り混じる事になり、短いパケットは損になる、大きいファイルは得をする、というのはわかりますが、パケットはかなり短いというイメージでした。
auやdocomoのホームページでは128Byte という事なので、1024bit。そこに付加情報が付くのでもっとデータサイズは小さいですよね。
リクエストとは複数のパケットがつながって、まとまってキューに入り、他のリクエストと混じる事は無いんですかね？ちょっとよくわからなくなりました。
もしそうだとすると、全員が処理の優先度は同じでも、人により速度が異なるという事はあり得ますね。
すみません、ここまで細かくなってくると私には説明しきれません。
通信に関しては、まずは「OSI ７階層モデル」を知っていただく必要がありそうです。
http://www008.upp.so-net.ne.jp/mkusanagi/network/osi.htm
あたりが参考になるかと。
あとは、TCP/IP、UDPやQUICといったプロトコルに関してもある程度把握してください。
※たとえば、TCP/IPだとウインドウサイズやMTUというものがあり、状況に応じて一度に送受信するデータ量が変わってきます
TCP/IPでデータ転送をする際のパケットの様子を説明したブログがありましたので参考までにご覧ください。
http://blog.shibayu36.org/entry/2018/03/08/193000
> auやdocomoのホームページでは128Byte という事なので、1024bit。そこに付加情報が付くのでもっとデータサイズは小さいですよね。
その128バイトはパケットと呼んでいるもののサイズだと思います。それは料金計算のための数字であって、実際の通信がそのサイズで行われているのではないと理解しています。
> ではここで疑問なのは、配信速度制限ですが、mineoの話では
>「回線単位ではなく、各通信単位でかかります。」
> という事なので、リクエスト単位でかかっているという意味なのでしょうかね。
「各通信単位」というのは多分OSIの第5層「セッション層」のことだと思います。
多くの方に理解していただけるように簡略化して図にすると、それはそれで突っ込みどころが増えてしまう。かと言って精密に記述すると1枚の図では到底説明できないし、ほとんどの方は意味不明になるという悩ましさを技術者の方はお持ちのはずです。
> 帯域制御が上手く機能している前提なら、もちろんその話はアリだと
> 思います。
> お昼のパケロスは減っていないという話も聞きます。
> それでも単位当たりの原価が減っているなら意味はあると思いますが、
> どうなんでしょうね。
既に何度も書いているかと思いますが、そもそも帯域制御をするに至った原因として考えられるのは、単に帯域が足りない以上に「接続リクエストが多すぎる」事にあると私は観ています。
とはいえ根拠法である電気通信事業法でも接続リクエストを拒否する訳にはいかないのでオーバースペックになっても接続を受け入れ、実際のデータ送信を後回しにする。このためには何らかの形で「データを貯め込むバッファが必要」となります。
そのために帯域制御を行うに至った、と考えるのが自然です。帯域制御ありきでその様な形になったわけではないと考えています。
ですので「帯域を絞ると云々」ではなく「接続リクエストを何とか叶えるためには結局帯域を絞るしか現実解がなかった」と考えなければ単なる「ああ、帯域絞ってこうなるね。これは許せないね」になりませんか？
過去スレッドで何度も書いていますが、現状の混雑は接続リクエスト(つまりはユーザーの利用集中)が原因で起きているのが明白かと思います。
そういう場合に接続拒否を行えればそもそも混雑集中もある程度収まりますが、ユーザーからは通信機会の不公平が発生します。
しかしその様な状況は法律で禁止されている行為ですから、何とか接続リクエストを受け入れなければならない。そのためには「帯域を絞ってでも接続リクエストを受け入れなければ」につながったと考えています。
いずれにせよユーザー都合の前提だけで考えていくとユーザー＜＞事業者間で不信が鬱積するだけだと思います。
※本当は混雑時を避けて使うことが「帯域制御などという小手先の手段」を
回避するためには最適ですが、時間の制約もあるので通常は難しい
ことだと思っています。
URL紹介ありがとうございます。
128bytesは料金計算単位であって、送受信サイズではないのですね。知りませんでした。
実際には、サーバーと端末間で、動的にHTTPレスポンスのデータの長さが決められていて、その単位でパケットが分割されているという事なんでしょうか？リンク先のTCPパケットの様子を見る限り。
という事は、セッションごとにパケットの長さは異なっていて、速度に有利な接続と不利な接続が、POIを通過する時には、混在しているという事ですかね。
UDP（QUIC含め）は、送達確認をせず送りっ放しだから送受信量が減る、QUICは欠落分を自動復活できる、という認識程度ですが、、、
QUICだけが速くて問題だという訳ではなく、元々プロトコルや同じプロトコルでもセッションによって、送受信の速度に大きな差があるのが普通だという事なんですかね。
＞単に帯域が足りない以上に「接続リクエストが多すぎる」
＞何らかの形で「データを貯め込むバッファが必要」となります。
接続リクエストをバッファに貯める為に、帯域を絞っているという意味ですか。
帯域を絞るという事は、それだけバッファに貯めて置いて、少しずつ消化して行くので、余計にバッファをたくさん使う印象ですが、、、
それは置いておくとして。
データのダウンロードより、とにかく「接続」を先にして、セッションをどんどん張ってしまえ、みたいな事ですかね。
そっちの方が全体に遅くなりそうな気がしますが、そっちの方が「接続タイムアウト」状態にならなくて良いとかですかね～？
https://king.mineo.jp/my/27dd1b80f1465c71/reports/5691?page=1#comment_section
具体的には、特定サイズ以上の大きいファイルをダウンロードすると、速度が遅くなる、という情報が複数報告されていたとか。
今年４月頃ほど極端ではなくとも、この頃から、何かの制限はしていた可能性がありますよね。（と思っています）
> 実際には、サーバーと端末間で、動的にHTTPレスポンスのデータの長さが決められていて、その単位でパケットが分割されているという事なんでしょうか？リンク先のTCPパケットの様子を見る限り。
結構近いですが、以下のように捉えていただいた方が良いかもしれません。
HTTPリクエストに対して、HTTPレスポンスが返ります。
HTTPレスポンスのデータ量は、HTTPリクエストの内容やサーバのデータ状態によって変わります。
このレスポンスデータは複数のパケットに分割されて、TCP/IPプロトコルに従って運ばれます。
その際のパケットのサイズは通常はMTU（Maximum Transmission Unit）で決まります。
MTUに関しては
https://ja.wikipedia.org/wiki/Maximum_Transmission_Unit
> という事は、セッションごとにパケットの長さは異なっていて、速度に有利な接続と不利な接続が、POIを通過する時には、混在しているという事ですかね。
通常はセッション毎では無いです。クライアント、通信経路とサーバの組み合わせで決まることが多いです。
ということで「速度に有利な接続と不利な接続」的な事象は起こり得ますが、通常それはmineoが制御しているものではなく結果に過ぎないという理解です。
> 元々プロトコルや同じプロトコルでもセッションによって、送受信の速度に大きな差があるのが普通だという事なんですかね。
通信は接続相手やそこに到達するための経路次第のところもありますから、mineoが速度制御していない場合でも送受信の速度は常に変化しているのが普通です。
MNO内部を通れる最大パケットは、DプランはMTU:1500(ヘッダ40byte、ペイロード1460byte)、AプランはMTU:1420(ヘッダ40byte、ペイロード1380byte)となっております。
どんな大きいサイズのデータもこのサイズ以下に分割されてネットワークを通過しています。
しゅうさんありがとうございます。
httpレスポンスがMTUより小さい場合、大きいパケットより不利になるという事はありそうですね。
ただ、レスポンスは複数回に分かれて来るので、その複数回受信の間に他のパケットが割り込む事はできますよね。
(出来なかったら1セッションが終わるまで専有になってしまう)
だから、一般には速度差はスタッフブログの図ほどはないと思うのですが、どうなんでしょう。(平日昼にQUICが40Mbps出てたとかは聞きますがQUICは再送無いらしいし)
あと、図のように5倍とかの差があるのなら、大きいデータを受信するスピードテストは、かなりブーストされた結果になってしまいますよね(ペーシング無し場合)。
Webアクセスのような小さい物だと、スピテスに押されて小さくなってしまいます。
QUIC自体は再送はあります。
盛り上がってるのでちょこっと横やりwMVNOに品質を求めるのは間違っていると思いますよ。
帯域制限が話題になっていたので平日お昼に試した結果です。
スレチ失礼m(__)m
> 接続リクエストをバッファに貯める為に、帯域を絞っているという意味で
> データのダウンロードより、とにかく「接続」を先にして、セッションを
> どんどん張ってしまえ、みたいな事ですかね。
> そっちの方が全体に遅くなりそうな気がしますが、そっちの方が
> 「接続タイムアウト」状態にならなくて良いとかですかね～？
帯域制御装置やロードバランサなどにはセッション保持(Session Keep-alive)の機能があります。要は「ここまでの時間は接続セッションを残しておく」ということです。
これだと通信機会の公平性は可能な限り担保できます。まあ、健全な状態とは言えないでしょうけどね。
ただセッションを始めから弾いてしまうとより早く輻輳状態とも言うべき回線混雑状況になりますし、ネットワーク管理をしない事で余計に通信混乱が発生しますので、通常は「通信帯域管理をしない」と公言してる MVNOでも何らかのセッション保持・管理機能を有する機器は後ろに居ます。(そうしないとネットワークがパンクする)
本当は「接続リクエストに耐えうるだけの設備を常時用意しておく」のが理想ではあるんですけど、それをやると「永遠に増加する通信要求とのいたちごっこ」になりますし、それ以前に「そこまで設備費用を掛けていられない」実情もあると思います。
>QUIC自体は再送はあります
え、そうなんですね。
QUICは再送信しなくても欠落したパケットを復元できるってどこかで読んだので、再送は無いと思っていました。
まいずれにしても言いたい事は、スタッフブログの図が本当なのかな、という事です。
ペーシング無しでは問題だらけという図に釈然としないです。
ペーシングのメリットとデメリットをきちんと説明してくれるなら、わかるんですが。
本当にそんなに良い事だらけなら、一日中やったらいいやんって話ですよ。
(別にPhantomさんへの苦情ではないです)
0.08Mbpsは、ほとんど通信できない速度ですよね。
他のスピードテストで試したら、もう少しは出るかも？
IIJmioでも、特定の通信を最適化するような事はしないそうですが、バッファをごにょごにょ何らかのチューニングはやってるような事は言っていましたね。
ただ、mineoのやり方は明らかに（少なくともGW明けまでは）失策でしたよね。徐々に改善して行っている印象はありますけど。
プレミアムコースの返金の件にしてもそうですが、もう少しちゃんとした検証やら複数人でのチェック承認体制やら必要だったんでは？と思わざるを得ないです。
> IIJmioでも、特定の通信を最適化するような事はしないそうですが、
> バッファをごにょごにょ何らかのチューニングはやってるような事は
> 言っていましたね。
それをやらないとフレームサイズ調整が出来ない固定長通信のみになってしまうので、結局リクエスト多発時や再送、データ破棄時など、帯域を有効活用できなくなってくるので致し方無いと思います。
> ただ、mineoのやり方は明らかに（少なくともGW明けまでは）失策
> でしたよね。徐々に改善して行っている印象はありますけど。
> プレミアムコースの返金の件にしてもそうですが、もう少しちゃんと
> した検証やら複数人でのチェック承認体制やら必要だったんでは？
> と思わざるを得ないです。
以前も他スレッドで書きましたけど、結局帯域制御なりロードバランシングって「机上の設計だけでは最適化(効率よく帯域も機器能力も使い切る、と言う意味です)しきれない」ので、絶対に実勢値なり本番導入後のチューニングは必要になるんですよ。
ただ、予告なくそれをやってしまうと色々と問題があるので本来は「徐々に条件を厳しくチューニングする」事が多いです。導入当初は「ほとんど何もしないに等しい(=まずはトレンドを取得しつつ可能な限り効果的な帯域制御方針を検討するため)」構成にすることが多いかと思います。
それとききなりソリューションの構成によっては「プロトコルレベルやポート番号レベルでの調整」しか出来ない場合があるので、こうなると巻き添えを食う通信もところどころ発生します。本当はこれらも動的に調整する機能があれば良いんですけどねえ。
※多分その辺りまで対応する機器になると、１台で億ション買える位の
金額にはなりますけどね。(詳細は伏せますが)
お詳しそうなので教えて欲しいのですが、通信のチューニングって、本番環境とは別に、テスト環境という物は作れないものなのですか？設計の後は即本番なのですか？
机上の設計の後すぐ本番導入、しかも本番環境で検証というのは、とても信じ難いのですが、通信関係ってそういうものなんですか？
もちろん十分検証した後でも、本番環境でしか起こらない現象が発生するというのは当然あるとは思うし、導入後のトラブルは必至というのは理解しますが。
でも、その前に設計段階でも検証段階でも、例えばプレミアムコースへの影響を忘れられていたとか、そんな事有り得るんですかねー。
> お詳しそうなので教えて欲しいのですが、通信のチューニングって、
> 本番環境とは別に、テスト環境という物は作れないものなのですか？
> 設計の後は即本番なのですか？
(以下略)
本音で書いてしまうと「テスト環境で本番と同じだけの負荷をかける事自体がまず不可能」ですので。ネットワークへの負荷を掛ける場合にセッション数を様々な拠点なり端末を駆使して張るとしても「閉じたネットワーク内で実験したのでは実勢とかけ離れた状態」ですから。
※設計はあくまでも「この様に動くはずだよね？」の前提です。それで
本番導入することもありますし、許されないようなサービスの場合は
何とか疑似環境を用意することになりますけど、それも非常に手間と
コスト、および検証期間が必要になります。
それと本番環境と言っても実際には「商用環境」でなければ本番扱いではない事も多々あります。実際に「同じものを購入するコストを考えたら商用環境への移行前にある程度性能測定する」位が可能な範囲です。
実勢値を求めるには商用環境のモニタリングが必要な場合も出てきます。言うまでもありませんが。
※逆に検証環境で本番環境と同じ状態が作り出せる、と考えるほうが
私は「設計者の驕り」だと思います。そんな簡単に検証した内容と
同じ結果が本番環境で出てくるなら、そもそも検証環境なんて
同じ構成にしなくても済むわけですし。(機能検証だけの最小構成で十分)
→検証環境で本番環境と「ほぼ同じ状況を模試」するには
「検証環境と本番環境が同じ構成でなければ意味がない(=投資が倍に
なる)」という前提を踏まえる必要があります。
そこまで投資できるのは法的に非常に規制が厳しい金融業界なども含めてごく一部です。(詳細は諸事情があるので省略します)
ありがとうございます。
本番とテストと同じ負荷を掛けるのは無理だと想像できますが、一般には別領域で検証は出来そうな気もしますが…
mineoの場合、もしかすると導入した装置の問題で、費用を掛けられず、多重の環境は作れなかったりするのかな、と想像したりします。
FiimoなどMVNEとして提供している所も、プレミアムコースも同一条件のようですしね。
うーん、なんだか不具合に遭っている方はお気の毒ですね。例えばVPNが使えなくなった人など…今回の件と関係あるか無いかわかりませんが。