アカウント名:
パスワード:
帯域ってユーザーが早いもの勝ちで専有できるってこと? これって、ユーザーが悪意持てば運営に妨害できるってことだよね。 こういうユーザの存在は当然仮定すべきだろうと思うのだが。 結局管理不行き届きってだけだったんじゃない? 他のプロバイダはどうしてるんだろうね。
素人ですいません。 そんな細かいコントロールってできるものなのですか?
公平制御とか言われていますが、もう結構前からそんな細かいコントロール可能な製品は出てる。
たとえばPureFlow GSX NF7101C [anritsu.com]>高精度な帯域制御で安定した通信品質をサポートする1G~10G対応のトラフィックシェーパーです。
2007年のアンリツテクニカル紙にPureFlowのCATV向け製品の開発概要が出てるから、採用していなかったとしてもそういう製品があることは(ISP事業を営んでいれば)知っていて当然のこと。CATV 向け公平帯域制御装置 PureFlow FS10-CATV の開発 [cdn-anritsu.com]
まあでも、今回のNUROの件はこの手の装置(Anritsuかどうかは知りませんが同種の製品)がそれなり入っていたのに帯域制御設定自体もまずかった雰囲気はあるんだよね....。輻輳レベルのパケットロス(ICMPで20-30%のロス)を起こしながら、届くときは接続先まで(安定して)ICMPのRTTが5-6msとか、帯域制御装置のシェーピングとポリシングの設定が外野からは理解不能な状況だった。どうみても帯域制御装置の設定がおかしかったようにしかみえない。(最近は輻輳時、RTT値が上がるようになった(=シェーピングのバッファがそれなり入った)模様)
ネットワークの混雑を制御するアルゴリズムに「公平な通信を提供しきれない」という問題があることが判明 [gigazine.net]
GIGAZINEをソースにしないで。TCPの輻輳制御と、回線事業者のシェーピングは話が違うでしょう。
想像だけど…
「複数エリアにて多数利用」ってのがキモなんじゃないかな。
これらが常時帯域を専有していたならNUROのチェックに引っかかるだろうけど、不特定多数が散発的に大量のトラフィックを発生させて、かつ個々のトラフィック総量がNUROの基準以下なら、今回のような事態が起こりうる。
何に利用すると、そういう通信が発生するんでしょうね。TCPだと輻輳が発生すると自身も速度低下するので、おそらくUDPの通信で帯域上限までトラフィックを流し続けていたのではと推測。動画配信のサーバーでも立てていたとすると、不特定多数が散発的に・・とはならず、サーバーのある回線だけが高トラフィックだったでしょうし。
輻輳が発生したらUDPだって無事じゃ済まないでしょ VPN/プロキシサーバでも立ててたんじゃ?
UDPで受け取る側は輻輳時はパケロスだらけでしょうが、送信側は途中区間に輻輳あるかパケロス発生してるかに関係無くせっせと送信し続けますよ。TCPと違って到達確認する仕組みが無いので、送信側は途中で輻輳でパケットが廃棄されている事自体知らないです。
単なるバグないし設定ミスで無駄なパケットが出てたとかじゃねーかなぁ 根拠ないけど
https://twitter.com/Abysstana_info/status/1573944573847490560 [twitter.com]被害をうけた人の情報だけど「落ちるタイミングは、X時00分, 40分など、時間的区切りが良い時に起きやすい傾向かも?」って書かれてる。発動時間についての書き込みは少ないというか既に埋もれてしまって探しにくいんだが、全国的に普及している企業によるIoT関連機器のバッチ処理とかプログラムのミスなんかだったりしないかな。
先に繋いでた人が帯域を維持できるなんてことは無くて皆平等に遅くなるだろ。PPPoEマルチセッションとか、ファイル転送を高速化するために複数のセッション張ったりする時にどんな動作になるかは知らん。
NUROはPPPoEなんか使ってないよ。IPoEだけどIPv4もトンネルじゃなくてデュアルスタック。auひかりもだいたい同じ
> これって、ユーザーが悪意持てば運営に妨害できるってことだよね。
GOLを思い出すな。DDOS返しを食らったんだっけ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
回線占有率のバランシングってしてないの? (スコア:0)
帯域ってユーザーが早いもの勝ちで専有できるってこと?
これって、ユーザーが悪意持てば運営に妨害できるってことだよね。
こういうユーザの存在は当然仮定すべきだろうと思うのだが。
結局管理不行き届きってだけだったんじゃない?
他のプロバイダはどうしてるんだろうね。
Re: (スコア:0)
素人ですいません。 そんな細かいコントロールってできるものなのですか?
お金さえあれば、できますよ (スコア:4, 興味深い)
公平制御とか言われていますが、もう結構前からそんな細かいコントロール可能な製品は出てる。
たとえば
PureFlow GSX NF7101C [anritsu.com]
>高精度な帯域制御で安定した通信品質をサポートする1G~10G対応のトラフィックシェーパーです。
2007年のアンリツテクニカル紙にPureFlowのCATV向け製品の開発概要が出てるから、採用していなかったとしてもそういう製品があることは(ISP事業を営んでいれば)知っていて当然のこと。
CATV 向け公平帯域制御装置 PureFlow FS10-CATV の開発 [cdn-anritsu.com]
まあでも、今回のNUROの件はこの手の装置(Anritsuかどうかは知りませんが同種の製品)がそれなり入っていたのに帯域制御設定自体もまずかった雰囲気はあるんだよね....。
輻輳レベルのパケットロス(ICMPで20-30%のロス)を起こしながら、届くときは接続先まで(安定して)ICMPのRTTが5-6msとか、帯域制御装置のシェーピングとポリシングの設定が外野からは理解不能な状況だった。
どうみても帯域制御装置の設定がおかしかったようにしかみえない。(最近は輻輳時、RTT値が上がるようになった(=シェーピングのバッファがそれなり入った)模様)
Re: (スコア:0)
ネットワークの混雑を制御するアルゴリズムに「公平な通信を提供しきれない」という問題があることが判明 [gigazine.net]
Re: (スコア:0)
GIGAZINEをソースにしないで。
TCPの輻輳制御と、回線事業者のシェーピングは話が違うでしょう。
Re: (スコア:0)
想像だけど…
「複数エリアにて多数利用」ってのがキモなんじゃないかな。
これらが常時帯域を専有していたならNUROのチェックに引っかかるだろうけど、不特定多数が散発的に大量のトラフィックを発生させて、かつ個々のトラフィック総量がNUROの基準以下なら、今回のような事態が起こりうる。
Re: (スコア:0)
何に利用すると、そういう通信が発生するんでしょうね。
TCPだと輻輳が発生すると自身も速度低下するので、おそらくUDPの通信で帯域上限までトラフィックを流し続けていたのではと推測。
動画配信のサーバーでも立てていたとすると、不特定多数が散発的に・・とはならず、サーバーのある回線だけが高トラフィックだったでしょうし。
Re: (スコア:0)
輻輳が発生したらUDPだって無事じゃ済まないでしょ
VPN/プロキシサーバでも立ててたんじゃ?
Re: (スコア:0)
UDPで受け取る側は輻輳時はパケロスだらけでしょうが、送信側は途中区間に輻輳あるかパケロス発生してるかに関係無くせっせと送信し続けますよ。
TCPと違って到達確認する仕組みが無いので、送信側は途中で輻輳でパケットが廃棄されている事自体知らないです。
Re: (スコア:0)
単なるバグないし設定ミスで無駄なパケットが出てたとかじゃねーかなぁ 根拠ないけど
Re: (スコア:0)
https://twitter.com/Abysstana_info/status/1573944573847490560 [twitter.com]
被害をうけた人の情報だけど「落ちるタイミングは、X時00分, 40分など、時間的区切りが良い時に起きやすい傾向かも?」って書かれてる。発動時間についての書き込みは少ないというか既に埋もれてしまって探しにくいんだが、全国的に普及している企業によるIoT関連機器のバッチ処理とかプログラムのミスなんかだったりしないかな。
Re: (スコア:0)
先に繋いでた人が帯域を維持できるなんてことは無くて皆平等に遅くなるだろ。
PPPoEマルチセッションとか、ファイル転送を高速化するために複数のセッション張ったりする時にどんな動作になるかは知らん。
Re: (スコア:0)
NUROはPPPoEなんか使ってないよ。IPoEだけどIPv4もトンネルじゃなくてデュアルスタック。auひかりもだいたい同じ
Re: (スコア:0)
> これって、ユーザーが悪意持てば運営に妨害できるってことだよね。
GOLを思い出すな。DDOS返しを食らったんだっけ?