掲示板

【考え中】最大配信速度を抑制したら余計に混雑する、図を描きました!

(5月25日 やはり間違えているかも、考え中です)

mineoの通信最適化の話です。この話うんざりな方は見ないでくださいね。

先日、下記のスレッドを立てました。
「【算数の話】最大配信速度を抑制したら余計に混雑する」
https://king.mineo.jp/my/sato/reports/35311

私の説明が悪くて、理解して頂けない方が多く居られたようです。
で、しつこくも、別の説明図を作ったので紹介します。

mineoでは、最適化の一つとして「最大配信速度を抑制」をしています。※
速度制限をすると、制限した速度以上に、余計に通信が混雑してしまいます。最大速度が低くなればなるほど、混雑が悪化します。

※詳細はこちら。原則、動画のみ対象、混雑時のみ実施。
 https://king.mineo.jp/magazines/special/848

下は、(mineoではなく)全員が速度制限をされた場合の例です。

illust1935.jpg

こんな例を作りました。

1秒に5箱ずつ通信できる回線があります。
(※1箱とは、例えば1Mbitなどのデータ量の事です)
毎秒、平均5箱ずつ通信データがやって来ます。

この時、最大1人1秒に1箱までしか運べない(1Mbps)、という速度制限が付いた場合、どうなるでしょうか。


■A-1 帯域制限が無い場合(1人5箱ずつ)
1秒目にAさんが5箱、2秒絵にBさんが、3秒目にCさんが5箱、、、と一人一定頻度で通信リクエストがある例です。

帯域A-1.png

空いている帯域を占有できるので、1人5箱の通信が1人1秒で終わります。(1人5Mbps)


■A-2 帯域制限がある場合(1人5箱ずつ)
 1秒間に1人1箱しか運べない速度制限が付いた場合。

帯域A-2.png

5人で帯域を分けるので、全員1人5秒になります(1人1Mbps)。
この例では、一定頻度で一定数の通信をする為、常に帯域を5人で分け合っています。

この場合、制限前 1人5Mbps → 制限後 1人1Mbps
となり、帯域制限した割合だけ遅くなっています。
このイメージを持っている人が多いのでは?

ですが、実際の通信は、1人一定数の箱を運ぶ訳ではなく、沢山箱を運びたい人(大きいデータのダウンロード)、少ない箱を運ぶ人(文字だけのデータなど)色々な人が入り混じっています。
下はその例です。


■B-1 帯域制限が無い場合(1人当たりの箱数が異なる場合)

下の図のDさんのように、箱10個を運ぶ人が居たり、Gさんのように箱3個しか運ばない人が居たりします。

帯域B-1.png

BさんとCさんのように二人同時に通信リクエストがあれば、2人で帯域を分け合うので、この時1人当たりの通信速度は5Mbpsの帯域の半分の2.5Mbpsになります。

ただしこの例は、1秒間に平均5個の通信で、A-1やA-2と通信リクエスト数は変わりません。(図全体で55個)

この状態で1人1箱の速度制限が付いた場合どうなるでしょうか。



■B-2 帯域制限がある場合(1人当たりの箱数が異なる場合)
注意:これはあり得ない図です!!

通信リクエスト通り箱を積んで行くと、帯域よりはみ出してしまいます。
1人辺りの箱数が異なるので、図A-2のように帯域を5人だけで分け合う事ができません。

帯域B-2.png

帯域からはみ出した分は破棄されるのか? いやいや、下の図のように、皆で帯域を分け合って速度を落として通信をします。

再度書きますが、1秒間に平均5個の通信で、A-1やA-2と通信リクエスト数は変わりません。(図全体で55個)


■B-3 帯域制限がある場合(1人当たりの箱数が異なる場合)

下の9秒目以降のように、帯域を6人、7人、と多い人数で分け合う事になります。
箱を水平に輪切りにして、切った部分を後で通信するよう先送りして行っているイメージです。

帯域B-3.png

そうすると、細く長く通信する事になり、時間がかかります。つまり通信速度が落ちます。

1人1箱制限で速度が1/5になるかと思いきや、もっと遅くなってしまうのです。
つまり帯域制限をすると、混雑が余計に悪化する確率が上がるという事です。

このように混雑が悪化して行くと、バッファがあふれてパケット破棄やパケット再送が起き、そうなると更に混雑が悪化します。

再度書きますが、通信リクエスト数が多いせいではなく(図全体で55個)1人辺りが運ぶ箱数が異なるとこうなる場合があります。

特に大きいデータの通信が、仕掛中のまま長時間残っていると、後から来た通信の影響を受ける事になります。

この図を見て頂いて、「最大配信速度を抑制すると、余計に混雑する」という事を理解して頂けるでしょうか。

詳しい話は、下のスレッドに書いています。
「【算数の話】最大配信速度を抑制したら余計に混雑する」
https://king.mineo.jp/my/sato/reports/35311

興味ある方はご覧ください。


139 件のコメント
40 - 89 / 139
さと
さとさん・投稿者
SGマスタ
Tikitiki さん

>算数以前に最大配信速度を抑制したら余計に混雑するのは当たり前。
>前提とか抜きに直感でそう思うでしょ。

ほんとですか?凄いですね。
私はこの事を知ってビックリしました。

技術者さんが「え?」という事はさすがに無いと思いますが、
スタッフブログなどでユーザーがあまり問題提起していないので、気付いていない人が多いのだろうと思ってスレを立てました。
さと
さとさん・投稿者
SGマスタ
Kanon好き さん

そうですか。わかりにくいですか。
他の人に聞いてみたら、こちらの説明の方がわかりやすいと聞いたので、載せてみたのですが…

そもそも、最大配信速度よりも、POI混雑による速度の方が低い事は、確かにお昼休みなどはあると思います。
でも朝夕も最適化やっていますしね。
あと昼休み強制低速プランで安くなる話も出ていましたしね。

ばななめろん さんの話は、確かに「キャリア側通信が優先」は禁止されていますね。
さと
さとさん・投稿者
SGマスタ
Dark Side of the Moon さん

そうなりますよね。
1人6箱以上要求すると、今度は帯域が余ります。
なので、考え中です。
さと
さとさん・投稿者
SGマスタ
ヨッシーセブン さん

>帯域制限をしようとしなかろうと、同一時間に通信できる全容量は同じという考え方であれば、通信にかかる期待値は同じです。

そうなんですかね。
M/M/1待ち行列理論では、帯域幅が減ると減った帯域の割合以上に速度が落ちる(平均的な確率として)、と定義されていますが、これはどうなんでしょう。
http://objectclub.jp/technicaldoc/monkey/s_wait
退会済みメンバー
退会済みメンバーさん
ビギナー
やっぱり変なんで。
最適化の最大目的は再送されるパケットでの帯域圧迫を防ぐこと。
混雑ふくそうが発生した時の様々なアプリケーション破損を防ぐ目的。
VoIPに優先権を与える事でパケットロス補正。
プラス通信高速化を図る目的。
よって図による検証では間違った解釈となり兼ねないです。
同じ条件なら高速化に移行。
相互接続帯域を小さくして最適化を実行すればコスト削減。
なので、最適化では条件が同じなら高速化する方向になる。

横やり大変失礼致しました。
こんばんは♪
5箱しか通れない路はあまりに非現実的形容ではないでしょうか。
周波数変調もかかっていますし、多重化、OFDMの技術なしの説明は、誤解の増殖という気がします。
どうぞよろしくお願いいたします。
私も詳しくないので、正しいコメントではないと思いますが、
先生の処理スピードが半分になるという仮定がおかしいです。
処理スピード半分の先生が二人いると仮定しなければなりません。

水族館の事例も同じです。
処理速度の全体値を変更すると言う話と、同じ処理速度を分散して使うということは意味が異なります。
Kanon好きさん>
根拠法の条文はこれのことですか?

> 3  総務大臣は、前項(第七項の規定により読み替えて適用する場合を
> 含む。)の規定により届け出た接続約款が次の各号のいずれかに該当
> すると認めるときは、当該第二種指定電気通信設備を設置する電気通信
> 事業者に対し、相当の期限を定め、当該接続約款を変更すべきことを
> 命ずることができる。
>
> 三  接続条件が、第二種指定電気通信設備を設置する電気通信事業者が
> その第二種指定電気通信設備に自己の電気通信設備を接続することとした
> 場合の条件に比して不利なものであるとき。

これはキャリア側の接続条件と異なる設備条件でのサービスを禁止している、ということではないですか?
接続条件が異なるものであればサービス品質に差異も出ますからそれを合わせる必要性を説いているだけだと言えます。

キャリア側網内でのサービス品質を確保することはキャリア側として絶対条件ですし、確保不能な条件でサービス提供方法、接続条件を提示すればキャリア側も MVNO側もお互いに損失であるのは言うまでもないです。

> 四  特定の電気通信事業者に対し不当な差別的な取扱いをするもので
> あるとき。

「不当な差別的な扱い」の意味は「提供条件と異なる扱い」など、「不公平・不公正な扱いを禁止している」のでは?。

いずれにせよ仰る内容だと MVNOの通信によって混雑している場合はキャリア側サービスが混乱することになりますけど?。そんないい加減なサービス設計をしてたらキャリア側が滅茶苦茶になります。
少なからず「キャリア網内の輻輳防止を含めた提供条件での制限事項」を公表しているので、不公平でも不公正でもないはずですが?。

Kanon好きさんの仰る内容だと「MVNO側帯域の影響でキャリア側も巻き添えを食って網制御がおかしくなっても何とかしろ、と法律では書いている」と言うように聞こえてきます。それは「電波という公共財を扱うキャリア側に全て負担を押し付ける」だけになりませんか?
さとさん>
> 理想状態と異なるのはわかるのですが、IIJなども速度制限すると
> 却ってトラフィックが悪化すると言っているというのを聞きます。
> あと、今回のmineoは動画を狙っての事なので、動画以外に適用
> しようと思っての事ではないだろうとも思いますけどね。

動画の場合、必要なのはデータの正確さではなくリアルタイム性です。
YouTubeで採用している QUICは少なからず「データの正確さを必要とする TCPプロトコルではなくて、リアルタイム性を要求する UDPプロトコルでやり取りをする」ので、リアルタイム性を担保するのであれば「データを破棄すればよい」のです。(動画が飛ぶことになる)

こういうところが無駄なパケット転送の発生となるので、それを防止するために帯域制御も必要となる訳です。

※では途切れないように再生するには?と言う観点では「通信品質を
 下げて、必要なデータ量を自動的に減らす」事で解決できます。
 それらの制御はp「アプリケーション側で行う前提」でしょう。
 →そうでないと無理に同じ品質で再生しようとして輻輳は全く解決
  しません。(余計に酷くなる一方)
さと
さとさん・投稿者
SGマスタ
ヨッシーセブン さん

なるほど、そういう事か。
ちょっとわかって来ました。

という事は、帯域制限によって帯域が「余る」以外は、遅くなる要因は無いのかな。
私が書いた例のように、通信量はそのままで、回線数が増える(小さい通信が多数)という例でも遅くはなりますね。
もう少し考えます。
帯域制限がある事例と、帯域制限がない事例の絵で、異なるのが最初の4秒です。

帯域制限があるとした場合は、この4秒で能力を余らせています。

余らせることがある帯域制限であれば、遅くなってしまいますね。
余らせないのであれば、期待値は同じだと感覚的ですが思います。
>ばななめろんさん
>これはキャリア側の接続条件と異なる設備条件でのサービスを禁止している、
>ということではないですか?
その通りです。だからMNOの個別契約者よりもMVNO契約による通信の優先度を
下げると約款上の取扱と異なる事になり問題となります。

>MVNOの通信によって混雑している場合はキャリア側サービスが混乱すること
>になりますけど?。
優先通信扱いのものは別ですが、提供条件にMNO通信を優先するとは
書いてません。

MVNOと一般のMNO個別契約者の通信は同等です。
MNO個別契約者が優先ということはないでしょう。

>Kanon好きさんの仰る内容だと「MVNO側帯域の影響でキャリア側も巻き添えを
>食って網制御がおかしくなっても何とかしろ、と法律では書いている」と
>言うように聞こえてきます。
その時は、一般のMNO契約者とMVNOを同じ様に通信をコントロールすれば良い
かと思います。
そもそもMVNOも接続料を支払ってMNOのネットワークを利用している訳ですから
MNO契約者が優先される道理はないはずです。
>さとさんへ
ご質問の直列・並列の件ですが、
最初の図ではAさんのパケット5パケ分が1秒間にパラレル(並列)に通信回線上に乗っていて、同時間帯に他者の通信が出来ない(偶然他者のパケットが発生していない)状態です。この状態がBさん~Fさん分の各5バケ分タイミング良く到着して、ギリギリMAXスピードの通信が出来ている状態ですね。

変わって次の図やその次の図は各人のパケットがシリアル(直列)で次々と1秒間隔で届いている図ですね。

特に図3については、そのような形で細分化されるのでは無くて、パケットのサイズは基本的に変わりが無いと仮定すると、その回線(図の土管)の外に徐々にバッファの中で待機させられるパケットが増えるだけで、どんなに頑張っても1秒間には色々な人の1パケットが5個通るだけなのは変わりがないはずです。

同時に同一の人のパケットを最大5パケ通す事を許していたのを、同時には1とか2パケまでとするとかが、通信制限というふうに考えれば良いかと思います。
いずれにしても、その図の中だけで、仕組みを理解してもらうのは、若干無理があるように思われます。
さと
さとさん・投稿者
SGマスタ
甘栗大好きさん

そうか。荷物の大きさは、バケットとは想定していませんでした。
数Mbitとかの大きい単位で、分割可能という前提でした。
パケットなら分割できないので、3つ目の図はあり得ないですよね。

そこをまず書いてなかったので失礼しました。

それから、並列直列の意味も反対に捉えていました。他人と同時に通信するのが並列で、一人で回線専有するのが直列と思っていました。逆の話だったのですね。

いずれにしても分割可能かどうかの想定が違っていたことがわかりました。m(__)m
Kanon好きさん>
>> MVNOの通信によって混雑している場合はキャリア側サービスが混乱する
>> ことになりますけど?。
>
> 優先通信扱いのものは別ですが、提供条件にMNO通信を優先するとは
> 書いてません。

では、以下はどの様に説明されますか?

●電気通信事業法第34条第2項に基づく第2種指定
電気通信設備に係る接続約款
https://www.nttdocomo.co.jp/binary/pdf/corporate/disclosure/interconnection/term/dsj_all.pdf

> 第46条
> 当社は、通信が著しく輻輳し、通信の全部を接続することができなく
> なったときは、当社のFOMAサービス契約約款、Xiサービス契約約款
> 及び専用回線等接続サービス契約約款中通信利用の制限に係る規定、
> 並びにワイドスター通信サービス契約約款中通話利用の制限に係る
> 規定に準じ相互接続通信を制限することがあります。

ちなみに46条3項には

> 3 当社は、前2項の規定により相互接続通信を制限する場合には、
> 最大限の疎通の確保に努めます。この場合において、相互接続通信と
> その他の通信を公平に扱うものとします。

の記載がありますので Kanon好きさんのおっしゃる通りの記載もありますが、46条5項には

> 5 当社及び協定事業者は、相互接続通信又は他社相互接続通信を
> 制限する場合には、協定事業者と協議の上定める保守確認事項により
> 協力するものとします。

ともあるので「協定事業者と協議の上定める保守確認事項」の内容如何ではキャリア側通信の優先度を上げる条件での接続が可能になります。

詳細は NDAを締結している2社間の条件によりますが、設備・サービス維持などを含めて「業務圧迫の可能性がある条件下では通信が制限される可能性」を指摘していますので、QoS設定はそこに矛盾していないと感じます。
矛盾があるようでしたらご指摘ください。

※私自身も公開情報のみで判断しているので、この条件を読む限りでは
 「自社サービスを制限してまで条件を合わせる事を要求されている
 ものではない」と読み取れます。
さと
さとさん・投稿者
SGマスタ
ヨッシーセブンさんが言われている話が一眼正しい、的を得てる気がして来ました。
最初の帯域余りが無ければ、その後のゴチャゴチャもない訳ですから、帯域余り以外の問題は無い?のかな。
今までしてきた話を全部くつがえすような事ですね。
まだ考え中。
さとさん

さとさんの計算は最終的に全ての通信が完了すると言うことを前提にしているように思えますが、そもそも、お昼とか夕方の混雑時間帯では、全体の通信要求量がPOIの帯域を超えているので、パケットを破棄せざるを得ない状況が起きています。
パケットを破棄しないと、次々来る要求がたまって、いくらバッファがあっても足りなくて、結果としていつまで経っても応答が返ってこない事態になります。
帯域制限の方式にはいくつかありますが、例として下記を見てみてみてください。
http://www.fujitsu.com/jp/products/network/security-bandwidth-control-load-balancer/ipcom/material/data/3/1.html
さとさんの帯域制限は、最大の帯域を抑制するシェーピング しか考えていないようですが、MVNOで起きている混雑時の速度遅延はパケット破棄でしか解決できません。
そして、POIの帯域が足りない状況の時は、どのように捨てさせる(諦めさせる)しか制御の方法がない、というのが全体の状況になります。
本当に混雑しているときは、本来通信したい速度を落とさせて、一人あたりが使う帯域を小さくさせるしか有りません。

私が運営に指摘したのは、時間帯で一律に帯域制限すると、空いているかもしれない時でも常に制限されてしまうので非最適化になるということです。
さと
さとさん・投稿者
SGマスタ
コメントぞくぞくありがとうございます。
まだ全部理解しきれていないのですが...

とり急ぎ、帯域制限無しの、灰色部分の図がとおかしいですね。例えば6秒目にFとGが平等に分け合えていないなど。
帯域制御装置でも「オーバーコミット(空きがある場合は設定値以上に転送コスト[転送量]を配賦可能)」が使える前提であれば、元々の仮定自体がそもそも「帯域を制限する方向しか考えていない」となるんですけど。

※動的な帯域制御、かつ SDNの場合はオーバーコミットを許容する他に
 帯域共有グループを作って、その中では「最大配賦帯域内でそれぞれ
 余裕があれば追加可能」の動作も可能です。

ですので、単に帯域制限のみを考慮するとお話が狂ってきます。

※ベルりんさんも指摘されているパケット破棄の件はデータのリアル
 タイム性を重視する場合において「これ以上遅れるなら破棄してしまう」
 制御も行っていることです。
 さとさんの前提だと TCPフレームの条件のみとなっているので
 UDPフレームについては考慮が欠けていることになります。
退会済みメンバー
退会済みメンバーさん
ビギナー
帯域制限と関係なく「混雑するとダウンロードに時間がかかる」という説明になっているような気がします。一人6箱要求して、帯域制限しないと、後から来た人はずっと通信の開始ができなくなります。

あと、各ユーザーが必要とする通信量が固定というのが現実的ではないです。
各ユーザーが動画を高画質で5分観る、と決まっているならが適切な容量を確保してもらえばよいのですが、現実では高画質で5時間でも10時間でも見続けるユーザーがいるはずです。そのようなユーザーは帯域制限して、低画質で観てもらうという対策は有効だと思います。
さと
さとさん・投稿者
SGマスタ
たなまいさん

>帯域制限と関係なく「混雑するとダウンロードに時間がかかる」という説明になっているような気がします。

やっぱりそうですよね。


>一人6箱要求して、帯域制限しないと、後から来た人はずっと通信の開始ができなくなります。

ずっと通信ができなくなるとは、どういう意味でしょうか?
バッファで待つとかではなく?
さと
さとさん・投稿者
SGマスタ
うーん考えましたけど、やっぱり間違っている気がして来ました。
やはりヨッシーセブンさんが言われている通り、帯域制限をして変わるのは、帯域に空きが出来た場合のみ、ですかね。

その空きこそが渋滞を生むのか…
とも考えましたが、違う気がしてきました。
さと
さとさん・投稿者
SGマスタ
帯域の空きにより遅くなって、そこから渋滞を生む、でいいのかな。
私自身は通信関係はほぼ素人なので、あくまで想像ですが、帯域制限で余らせるようなことはしないのではないでしょうか?
帯域制限の本来の目的は、多くの要求にたいして応答待ち時間を安定化させることのように思います。
帯域制限なしという図ではデータが正常に流れているように見えますが、今回混雑時の輻輳対策をしているということであれば、箱が5個流れてくるのに、流す幅が2個分しかないといったことを想定しないといけないのではないかと思います。

また、パケットロスや再送するという概念が抜けているようにも思います。
前のスレの水族館の行列の話は分かりやすいですが、通信と行列は同じなんですかね?
このスレを読んでもいまいちピンときませんでした。

私に通信の知識はありませんが、素人的にはコショウの蓋の目(穴)と粒をイメージしてます。
蓋の目の数を増やせばコショウの粒がどんどん出るのは当たり前かと思います。
目が詰まらないように粒の大きさを制限するのが最大速度制限かなぁと。
最大通信速度の抑制って、基本的に回線にその時点の全利用者のデータを回線上に切れ目なく乗せ切らない状態時に、誰の通信時間を間延び(ストリーミングデータを支障が出にくいスピードまで落とし(間延びした間に他のデータを割り込んで流す)て流す)させるかとか、間引き(写真データの圧縮)して短くなったデータ量分他のデータが流れる時間を作ってやるかが、今回明らかになった抑制の説明だったかと認識しております。

なので、大量のデータを流している人ほど割をくう制御なのだろうなと思っております。

さとさんの図では、必ず何方かのデータが次々と切れまなく(細くはなっていますが(笑))流れていますが、現実はそういった制御では全くないのだと思います。
さと
さとさん・投稿者
SGマスタ
ベルりんさん

通信量が増えてきたら、混雑して遅くなりますよね。(バッファが足りていてパケット破棄や再送が起こらない時)

例えば回線が空いていて一人で専有できる時と混んでいて複数人で使っている時には、速度が違いますが、これは人数で平等に分け合っているのですよね。(低速モードやペーシングなしで無制御の場合)

ですので、ある瞬間(一秒)に通信しているデータを輪切りにして確認したとしたら、その瞬間の人数が多いと遅く(一人分が細い)、人数が少ないと速い(一人分が太い)と思うのですが、合っていますか?

速度の遅延は、全体の通信量が増えると起こるという認識ですが合っていますか?

その前提でこの図を書いていますが、皆さんの話と前提が違うのかなあと思って確認です。

シェーピングと書かれているのは、意図的に速度を抑制する技術の事ですよね?
同時間の通信人数が増えれば、自然と速度が遅くなりますが、それはシェービングとは違いますよね。

最大配信速度の抑制は、動画の通信量を減らすためにやっているという認識です。動画は通信量を減らせるので、他の人の帯域が空くからです。

ですので、動画ではないデータ受信で最大配信速度を落とされたら、混雑緩和にはならないと考えてこのスレを立てています。

これら混雑緩和にならない、という図です。
パケット破棄の話がよく出ていますが、バッファが仮に無限にあって破棄が無い前提の例です。
パケット破棄が起こると再送が増えて更に混雑が悪化しますよね。ですので、この図に盛り込む必要は無いと思っているのですが、間違っているでしょうか。

L_image.jpg

さとさんが描かれたものと似ている図がスタッフブログに載ってますね。(^^

・通信の最適化によるお客さま影響について(ペーシング)
https://king.mineo.jp/magazines/special/848

実際こんなに上手く行っているのだろうかと思う所はありますが(^^ゞ
上のはバックオフアルゴリズムの問題点ですね
TCP/IPでは輻輳を防ぐのに使ってるのですが、大量に流す人がいると、そちらが優先されてしまって平等に配分されない現象が発生するのです
なんせ、30年以上前の設計なんで、これほど通信量が増えてキチキチになることもマルチメディアも考慮されてませんからね・・・

トラフィックシェーパーはQoSまではいかないまでも、その絵の動きを目指すものですね(^^)
さと
さとさん・投稿者
SGマスタ
図を取り急ぎ直しました。
では仕事行ってきます~また後程。
さと
さとさん・投稿者
SGマスタ
さて、やっと皆さんのコメントをじっくり読み始めました。

>ばななめろんさん

>すべての通信が同じ優先度で送受信されている様な、そんな理想的ネットワークは逆に設計上破綻します。

通信の内容によって優先度を変えるのは当たり前の事なのですか?
mineoは、去年の8月からペーシングを実施しているそうですが、その前までは平等な優先度で通信をしていると思っていました(つまりスピテスブーストをしていないと思っていた)。

IIJmioなども「最適化しない」と明言していますよね。これは通信の内容による優先度の制御をしないという意味だと思っているのですが、違う意味なのでしょうか?

詳しく知りたいです。
難癖をつけるようで申し訳ないのですが少々。


・Fがリクエスト指示(下部表記)よりも1秒早い、もしくは指示の表記場所が間違っている

誤記ですかね。

・「Aの比較」と「Bの比較」でリクエストを発するタイミングを変えている(BとC、HとI、JとKが同時にリクエストしている)

前提条件が回線の太さ(5Mbps)とデータの総量(55箱)しか考慮していなく、整合性が取れていないように感じます。
後半に要求人数が増えれば、混雑することは想像するまでもなく分かります。
3秒間という短時間のうちに5人のリクエスト(G~K)があれば、それは帯域制限うんぬんではなくとも「単に混んでいる」という印象を受けました。
例えば、5人が帯域を占有し続けてる状態で6人目、7人目がリクエストしたら、帯域制限していなくとも図と同じような混雑表記になると思います。

タイミングは「Aの比較」から変えず、個人が要求するデータ量だけを変えて図にしても良かったと思います。
さと
さとさん・投稿者
SGマスタ
朝目覚めてシャキーン! さん

パケットリダイレクトやブロック転送レート制御という言葉を知りませんでしたので、今検索したばかりなのですが、、、

この図は、物凄く簡略化したイメージで、複雑な制御はしていない前提、バッファは無限である前提で破棄も無いという話です。
説明したい趣旨は、待ち行列理論で仕事の速度を遅くすると遅くした割合以上に待ち時間が平均的に遅くなる、という事です。

mineoの最適化の1つであるペーシングは、動画を狙って動画の通信速度(と画質)を落とす事を目的としているようです。動画のビットレートを落としたら帯域が空きますので効果はあると思います。
ただ、動画以外にも誤ってペーシングが適用される場合があり、これが悪影響を及ぼす可能性があると心配しています。(実際に体感速度が悪くなった報告をよく見ます)

もちろん最適化のメリットはあるでしょうが(好むかどうかは別)、速度制限のデメリットもあるという事に気付いていない人も多いのではないかと思って紹介しました。
さとさん>
>> すべての通信が同じ優先度で送受信されている様な、そんな理想的
>> ネットワークは逆に設計上破綻します。
>
> 通信の内容によって優先度を変えるのは当たり前の事なのですか?

現実的なお話ですが、現在の電話系ネットワークを含めて、ほとんどの通信経路は IPネットワーク化しています。

※一部はフレームリレーや ATMなど別の形態をとっていますが、
 それらは初めから「通信内容なり帯域に対する保証を要求するもの」が
 中心ですし、同一通信品目だとした場合は IPネットワークよりも
 利用料金が高いです。(現在では銀行の勘定系通信やらかなり重要な
 通信に使われる状況です)

実際のところ、音声通信経路も事実上 IPネットワークの上に乗っています。詳細は伏せますがキャリア側の携帯電話網も事実上 IPネットワークで各基地局まで接続されています。

この場合、データ通信と音声通信が同一の通信品質(どちらも優先度が同じ)だとしたら、データ通信の割合が増えることで音声通信が途切れる可能性も発生しますから、自ずと音声通信はデータ通信よりもより高優先度で通信する必要があり、そのための優先順位を付けています。(QoSの設定はここで発生)

またキャリア側の通信約款にもありますが「優先着信電話の契約(災害用公衆電話などを含む)」に関しても通常音声契約よりも優先して発着信させる必要があるので、こういうものは基本的に通常契約よりも優先させるようになっています。

それ以外に関してはキャリア側の思惑なりサービス優先度によって設定の有無は変わってくる可能性も推察できますが、最終的に「通信が途切れることによってサービス品質が維持できなくなることが多大な影響を及ぼすもの」に関して、内部的に QoSを設定して優先通信を行っていることは容易に推測できるかと思います。

※同一の性格を持つ加入契約(いわゆる一般加入契約)同士の場合は
 基本的に優先度の設定はされていないはずです。
 それは電気通信事業法での禁止行為に該当するためです。
さと
さとさん・投稿者
SGマスタ
orion_ さん

Fがズレていたのは他の人からも指摘があり、直しました。

>「Aの比較」と「Bの比較」でリクエストを発するタイミングを変えている

リクエストのタイミングについては私も悩んでいる所なのですが、
「要求人数が増えれば、混雑する」というルールはあるのでしょうか?
私もよくその辺りの知識が無くよくわかりません。
なので「単に混んでいる」だけの図になってしまっているのか、先日から悩んでいます。

例えば、BとCに関しては、同時にリクエストをした方が全体が早く済んでいます。
更に、A~Eは全員同時にリクエストをしたとすれば、もっと早く済みます。
何故なら、土管の絵の左下の部分に、灰色の無駄領域があるので、これを使うので速まります。

タイミングAとBで一緒にする案は、後で試してみます。
時間がある時にじっくり見させていただきます。

通信の知識はさほどない自分でも
ほんとに対策になってるのか疑問でした。

・単純に、「最適化」という処理時間が増えるので、ここで時間が掛るので若干遅くなるんじゃない?
・仮に「最適化」で回線が空いたとしても、「最適化」までの待ちは考慮してる?
・受信バッファの先読み量減らす→動画が止まる確率が上がる→通信の向上する?

など。
無知な私の言ってることなので、的外れとは思いますが・・・
さと
さとさん・投稿者
SGマスタ
gavotte さん

ちゃんと記載していなくて、他の人にも誤解させてしまったようですが、5箱の箱は、1パケットの事ではないです。
例では1Mbitのデータと書きましたが、分割可能な大きな単位のデータ量を示しているつもりです。

基地局の無線通信の影響や、その他細かい事は(よく知らないのもありますが)全部無しで単純な話にしたつもりです。
時間をかけて低速で通信すると余計に混雑を招く確率がアップする、という単純な説明をしたつもりです。
さとさんへ、
運営さんのペーシングの仕組みの説明では、動画の通信速度を落とすことはあっても、視聴者が見る動画の画質を落とすとはどこにも述べられていません。

そんな事をしたら、動画と予想して、絞った通信は元の用をなさなくなり、正常な動きをしなくなってしまいます。

途切れ途切れの再生となる事を指して画質が維持出来ないという意味ならばそうかもしれませんが。(;^ω^)

さとさんの伝えたい事は、結果的に多くの利用者の通信サービスが出来る形になったとしても、全体として絞られた通信利用者以外も間延びした通信しか出来ない状態になる利用者が多くなり、快適性は損なわれる事を伝えたいのだろうと理解しております。
さと
さとさん・投稿者
SGマスタ
ばななめろん さん
以前のコメントへのお返事ですが。

>動画の場合、必要なのはデータの正確さではなくリアルタイム性です。

動画の配信速度を落としたら、ビットレートを自動的に下げて、データ量そのものが減りますので、帯域を空ける効果があるのはわかります。

問題は、動画以外の大きなファイルのダウンロードなどにも、ペーシングが誤って適用されていると思われる報告が多い為、デメリットを知ってもらいたいと思いました。
制限された分だけ遅くなって困る、だけではなくもっと混雑を招く可能性があるという事です。
さと
さとさん・投稿者
SGマスタ
ばななめろん さん

>※動的な帯域制御、かつ SDNの場合はオーバーコミットを許容する....

mineoは最大配信速度がどうなっているか明らかにしていないですよね。
でもユーザーの皆さんが調査した所、初期バースト2Mbpsその後1Mbps固定、という条件のようで、動的に変わっている様子は無いと聞いています。


>TCPフレームの条件のみとなっているのでUDPフレームについては考慮が欠けていることになります。

これはどういう意味でしょうか?(知識が無くてわからない)
UDPの方が送受信エラーの照合をしていなくて、パケット再送が無いらしいという話は聞いた事がありますが。
さと
さとさん・投稿者
SGマスタ
たなまい さん

>現実では高画質で5時間でも10時間でも見続けるユーザーがいるはずです。そのようなユーザーは帯域制限して、低画質で観てもらうという対策は有効だと思います。

mineoのペーシングの目的はそれで、低画質で見て貰う為だと思います。
公式発表ではなんかぼやかした書き方をしていますが、ビットレートを下げて画質を落としたい、以外の解釈が出来ません。

画質を落とされるのを好むかどうかは置いておいて、帯域を空けて混雑対策をする目的としては有効だと私も思います。

ですが、動画かどうか暗号化されてわからない為、機械が自動で動画っぽいと推測してペーシングをかけているそうです。
その誤判定が結構あるようで、動画ではない大きなアプリのダウンロードなどが体感上凄く遅くなったりしているようです。
このような悪影響は、単に本人が遅くなって困るだけではなく、帯域全体に悪影響を及ぼす可能性がある為、私は問題視しています。
さと
さとさん・投稿者
SGマスタ
ヨッシーセブン さん

>帯域制限で余らせるようなことはしないのではないでしょうか?

これは私もよくわかりません。

>帯域制限の本来の目的は、多くの要求にたいして応答待ち時間を安定化させることのように思います。

目的は、動画の圧縮(ビットレートを落とす)だと思っています。
というのは平日昼休みでもyoutubeのQUICプロトコルでは、数十Mbps出ていたそうです。これが昼休み1Mbpsに制限されれば、随分帯域は空くと思います。

でないと、昼休みはそもそも1Mbps出ていませんので、その混雑時に1Mbpsの速度制限をしても何の効果もありません。
効果が出るとすればQUICへの対策しか考えられないです。
さとさん>
> 問題は、動画以外の大きなファイルのダウンロードなどにも、
> ペーシングが誤って適用されていると思われる報告が多い為、
> デメリットを知ってもらいたいと思いました。

これを予防するにはそれこそ通信内容を完全に全て検閲して云々、と
しなければならないので、それこそアウトだと思います。

※なので機械的に「データ通信の振る舞いやら使用されるポート、
 プロトコルから自動判断する」ようにしてるだけです。

> 制限された分だけ遅くなって困る、だけではなくもっと混雑を招く
> 可能性があるという事です。

実際のところ、通信速度低下の要因は主に「通信リクエストの処理能力不足」が挙げられます。それだけリクエストが集中している状態では「いくら設備増強しても持ちこたえられない」訳ですし。

ですので「現有設備で何とか運用していく」ところを考えての帯域制御、という側面も本来は考慮が必要です。

※そのために一番良いのは Webアクセスにおける Sorry Serverの
 ように「一定以上のリクエストが発生した場合はすべて Time out」と
 する方法ですが、これは電気通信事業法の規定から取り得ない措置です
 ので、そもそも採用不能です。
さと
さとさん・投稿者
SGマスタ
ベルりん さん

帯域制御入門のリンク紹介ありがとうございます。
mineoでは混雑時しかペーシングをしていないので、目的はyoutubeの速度を絞る為だけだと思っています。
でないと、元々昼1Mbps出ていないのに、帯域制限する意味は無いですから。

>私が運営に指摘したのは、時間帯で一律に帯域制限すると、空いているかもしれない時でも常に制限されてしまうので非最適化になるということです。

私もこれは強く思います。
ただ適用時間が減りましたので、随分ましになりました。
あと適用時間中でも、GW頃よりも体感速度がましになった気がします。何か調整されているのですかね。

あとは誤判定で大きなファイルダウンロード時にも遅くなっているらしい事です。テザリングでメール送受信などすると劇的に遅く感じます。
さと
さとさん・投稿者
SGマスタ
MVNO-user さん

>箱が5個流れてくるのに、流す幅が2個分しかないといったことを想定しないといけないのではないかと思います。

ご指摘ありがとうございます。
ただ私の頭では難しくて、計算できません💦

せいぜい書けるのが、元々混雑していない回線に帯域制限をしたら、混雑が発生し得る、という事だけです。

>また、パケットロスや再送するという概念が抜けているようにも思います。

混雑が発生する前までの話をしたつもりなので、バッファ溢れによるパケット破棄などは書いていません。(どう計算したら良いかよくわかっていないというのもありますが…)
さと
さとさん・投稿者
SGマスタ
てんがろんさん

>通信と行列は同じなんですかね?

ヨッシーセブンさんからも指摘があったように、この例のような複数の列で複数の窓口という図は、M/M/1待ち行列(窓口1つ列1本)とは違う計算方法になると思われます。

じゃあ何理論になるのか、という事は難しくてわかりません(すみません💦)
ただ、パケット単位で見た場合は一列の行列であり、平均の処理速度は落ちているので、無理やりM/M/1に当てはめる事もできるのかも(?)

ただ、ニュートン算と同じく、仕事に時間をかけてダラダラすると、邪魔する要因の影響が強くなって余計に遅くなる、という考えは同じだと思います。

>目が詰まらないように粒の大きさを制限するのが最大速度制限かなぁと。

mineoもそんな風に上手く調整してくれていたら良いのですが…
さと
さとさん・投稿者
SGマスタ
甘栗大好き さん

>(ストリーミングデータを支障が出にくいスピードまで落とし(間延びした間に他のデータを割り込んで流す)て流す)させるかとか、

私もそういう目的でやっていると思います。
ストリーミングは間引きできますが、アプリのダウンロードなどはファイルを間引きする訳に行かないので、悪影響しか無い気がします。

>動画の通信速度を落とすことはあっても、視聴者が見る動画の画質を落とすとはどこにも述べられていません。

そうですね。誤魔化しなのか、だんだん言わなくなりましたね(笑)。
こっちには書いていますよ。
https://king.mineo.jp/magazines/special/845
「また、最大配信速度を抑制することで配信品質・ビットレート(720p、360pなど)を抑えることができ...」
つまり動画の画質を低下させる目的だという事です。これは動画アプリが回線速度に合わせて自動的にやってくれます。

>さとさんの伝えたい事は、...快適性は損なわれる事を伝えたいのだろうと理解しております。

速度アップの為にしているならまだわかるのですが(それでもスピテスブーストは嫌いですが)、逆効果になっている部分があるので、指摘したいと思いました。でも以前よりはましになっていると思います。
さと
さとさん・投稿者
SGマスタ
ばななめろんさん

>通信速度低下の要因は主に「通信リクエストの処理能力不足」が挙げられます。

これは帯域が狭いという意味ですか?それとも違う意味ですか?
さと
さとさん・投稿者
SGマスタ
Kanon好き さん

>さとさんが描かれたものと似ている図がスタッフブログに載ってますね。

見ました見ました。
不思議なのが、そのペーシング前の図で、特定の通信が他の通信を押しつぶしているように見えます。BさんAさんがCさんを圧し潰しています。
同じ帯域を同じ時間に使っていて、人により(通信内容により)優先度が違うという事はあるのでしょうかねー。

それを改善して3人平等にします、みたいな図になっていますが、そもそも不平等だったのか、という事が不思議仕方ないです。
どういう意味なんでしょうね。
コメントするには、ログインまたはメンバー登録(無料)が必要です。