アカウント名:
パスワード:
利用者からすれば利用料金の上限が設けられているほうが安心だし、といって少数のヘビーユーザーによって有限の通信リソースを独占されても困るわけで、このへんが妥当な落としどころでしょう。
欲を言えば、ある転送量に達するといきなり遅くなるのではなくて、段階的に制限がかけられていくほうが公平性は高いとは思いますが。（理想は、利用料金の伸びが対数関数的で、通信速度が調和級数的に抑えられる感じ？）
>妥当な落としどころいつもこの手ので思うのは、ヘビーユーザーのパケットの優先度を下げるだけじゃダメなんですかねぇ。通常ユーザーのパケットはDiffServのAF12 (廃棄確率=中)、ヘビーユーザーのパケットはAF13 (廃棄確率=高)を立てるといった感じで?
diffservはボトルネックの場所で動かさないと意味がないからダメ。
3G/LTEのボトルネックはdiffservを動かすようなコア網内じゃなくて末端の無線部分なので、コア網内が空いてても絞らなきゃダメ。
じゃあ混んでる無線のところでdiffserv動かせばいいじゃん、と思うかもしれないけど、末端はそもそもIPじゃなかったりユーザ識別できなかったりするのでやっぱりダメ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
これでようやくXiが検討対象になる、という人も多いのでは？ (スコア:2)
利用者からすれば利用料金の上限が設けられているほうが安心だし、といって少数のヘビーユーザーによって有限の通信リソースを独占されても困るわけで、このへんが妥当な落としどころでしょう。
欲を言えば、ある転送量に達するといきなり遅くなるのではなくて、段階的に制限がかけられていくほうが公平性は高いとは思いますが。（理想は、利用料金の伸びが対数関数的で、通信速度が調和級数的に抑えられる感じ？）
Re: (スコア:0)
>妥当な落としどころ
いつもこの手ので思うのは、ヘビーユーザーのパケットの優先度を下げるだけじゃダメなんですかねぇ。
通常ユーザーのパケットはDiffServのAF12 (廃棄確率=中)、ヘビーユーザーのパケットはAF13 (廃棄確率=高)を立てるといった感じで?
Re:これでようやくXiが検討対象になる、という人も多いのでは？ (スコア:0)
diffservはボトルネックの場所で動かさないと意味がないからダメ。
3G/LTEのボトルネックはdiffservを動かすようなコア網内じゃなくて末端の無線部分なので、コア網内が空いてても絞らなきゃダメ。
じゃあ混んでる無線のところでdiffserv動かせばいいじゃん、と思うかもしれないけど、末端はそもそもIPじゃなかったりユーザ識別できなかったりするのでやっぱりダメ。