フローとは
フローに要求される品質 : QoS
帯域、遅延、ジッター、ロスの四つのパラメータで特徴づけられる。これらすべてのパラメータによって、フローに要求されるQoS(Quality of Service:サービス品質)で決まる
- 帯域はHzかな？
- 遅延は出力に時間がかかってるとしか分かっていない
- ジッターとは？
- ロスとは?
アプリケーションの種類ごとの要求されるQoS
例えば、ネットワークは
信頼性の高いファイル転送のためにロスのない通信を実現する必要がないし、音楽や動画の再生のために常に一定の遅延での通信を実現する必要もない。
前者の例ではある程度のパケットロスが発生しても再送を行えば修復可能であるし、後者の例では受信側でバッファリングを行うことによって、ある程度のジッターであれば平滑化できる。しかしながら、ネットワークの帯域が狭すぎたり遅延が大きすぎたりすると場合は、アプリケーションによる品質の改善は期待できない。
- すべてのアプリケーションが上の４つの要件をすべて優れたものにしなくてもいい
- それぞれでカバー（再送、バッファリングなど）すればなんとかなる
- 帯域が狭すぎたり遅延があまりにも大きいとカバーが間に合わない
- バッファリングに関しての体験はyoutube再生時、いきなりオフラインにしても少しの間だけ再生される
- 帯域はパケットがどれだけ流れるか
- 一定の遅延とは？
通信の遅延
電子メールやビデオなどのファイル転送アプリケーションは遅延に敏感ではない。すべてのパケットに一様に数秒の遅れがあっても、特に害はない。いっっぽう、
ウェブサーフィンやリモートログインなどのインタラクティブなアプリケーションは、それらよりも遅延に敏感である。電話やビデオ会議のおゆなリアルタイム・アプリケーションは、遅延に対する要求がさらに厳しい。例えば、電話での会話のごとばがすべておくれて相手に届いた場合、その電話は使い物にならないであろう。一方、サーバー上にある音声や動画を再生する場合には、遅延が多少多くても問題にはならない。
- 電話、テレビ電話などのリアルタイムに要求されるものは遅延に敏感
- 電話が遅れたりすると会話ができない
- インターネットで調べ物をするときもサイトの開く時間が遅れるとイライラする
ジッター: 遅延やパケット到着時間の変化
遅延やパケット到着時間の変化(標準偏差)
（電子メール、ファイル転送、Webアクセスは）パケットの到着時間が不規則であっても影響を受けない。
遠隔ログインはややその影響を受け、ジッターが大きい場合には画面の更新がぎこちなくなってしまう。動画や、とりわけ音声は、非常にジッターに敏感である。ユーザーがネットワークを通して動画を見ている時に、すべてのフレームパケットが正確に2000秒だけ遅延しているような時は全く問題は起きないが、遅延が１秒と２秒の間でランダムに変化するような場合には、アプリケーション側でジッターを隠さない限り、視聴に支障をきたすことになる。オーディオの場合は、数ミリ秒のジッターでもはっきりと聞き取ることができる。
- 2000秒は30分以上だが正確に遅延すればいいのか？
- 遅延やパケットの到着時間の変化あると滑らかに出力できないのか
パケットロス
（電子メール、ファイル転送、Webアクセス、遠隔ログインは）すべてのビットが正しく配信される必要があるため、
動画や音声よりもロスに関する要求品質が高い。通常は、トランスポート層で、ロスしたパケットの再送を行うことで、この要求品質が達成される。これは無駄な処理であるため、パケットロスが発生しそうなことが事前に分かっている場合には、ネットワークがパケットの転送を拒否する方が本来は望ましい。音声や動画のアプリケーションでは、一瞬の音声が停止したり時折フレームが飛ばされたりしてもユーザーは気づかないため、ロスが発生しても再送を行う必要はない。
- 一つ一つのパケットの内容が重要なアプリケーションはロスに対して高い要求がある
- 連続性のある音声、動画は小さなコマが飛んでも気づかない
QoSの種類
- 固定ビット・レート（例：電話）
- リアルタイム可変ビット・レート（例：圧縮ビデオ会議）
- 非リアルタイム可変ビット・レート（例：オン・デマンド映画視聴）
- 利用可能ビット・レート（例：ファイル転送）