| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:dpi:dpi_options:use_cases:opt_uplink [2024/09/26 15:29] – external edit 127.0.0.1 | en:dpi:dpi_options:use_cases:opt_uplink [2025/04/16 13:26] (current) – [Configuration:] elena.krasnobryzh |
|---|
| listen to music, visit entertainment portals, etc. | listen to music, visit entertainment portals, etc. |
| |
| <note important>The peak of the channel usage occurs about 23 hours and usually lasts less than an hour, exceeding normal rates by 30%. | <note important>The channel utilization peak occurs around 11 PM and usually lasts less than an hour, exceeding normal levels by 30%. During this time, torrent traffic can account for up to 30% of the channel, about 50% is taken up by online video streaming, and only 20% is used for everything else.</note> |
| And meanwhile, the torrent traffic at this time can occupy up to 30% of the channel capacity, about 50% accounts for viewing online video, everything else accounts for only 20%.</note> | |
| |
| ====What we want to get:==== | ====What we want to get:==== |
| |
| ====Configuration:==== | ====Configuration:==== |
| Let's divide the traffic into classes depending on the protocol used. There are can be assigned in total up to 8 classes, which the SSG can use to label the packets both in the DSCP/TOS field of IP headers and the VLAN/MPLS priority field, and then the external platform can control QOS. But we will consider the case when the SSG does it on its own. | Let’s divide the traffic into classes based on the protocol used. Up to 8 classes can be assigned in total, which SSG can use to mark packets either in the DSCP/TOS field of IP headers or in the VLAN/MPLS priority field. After that, QoS can be managed by an external platform. But we will consider the case when the SSG does it on its own. |
| We place in the lowest priority class all the services that we can afford to be limited during peak hours. Usually these are services having the speed depending on external factors, it's the case when the user doesn't use the service in interactive mode but instead in the background one. The examples of such a services are: downloading files via torrent trackers, software update services and maybe something else specific to your case. Online broadcasting services being able to adapt to the available bandwidth and select the quality needed should be placed in a class with a higher priority, and, finally, in the highest priority class we should place interactive services, which operation is controlled by the user in online mode, so when the problems ocсur, they will become immediately perceptible; these are web browsing, online games, IP-telephony (SIP, Skype). And to put it simple, we will place everything else in this class. | We place in the lowest priority class all the services that we can afford to be limited during peak hours. Usually these are services having the speed depending on external factors, it's the case when the user doesn't use the service in interactive mode but instead in the background one. The examples of such a services are: downloading files via torrent trackers, software update services and maybe something else specific to your case. Online broadcasting services being able to adapt to the available bandwidth and select the quality needed should be placed in a class with a higher priority, and, finally, in the highest priority class we should place interactive services, which operation is controlled by the user in online mode, so when the problems ocсur, they will become immediately perceptible; these are web browsing, online games, IP-telephony (SIP, Skype). And to put it simple, we will place everything else in this class. |
| There are exist two approaches for limiting traffic for each class: to limit the maximum bandwidth that the traffic of corresponding class can occupy, or rely upon the mechanism originally provided by the SSG allowing to borrow bandwidth automatically. In the latter case, the SSG will begin to limit traffic based on classes only when the usage of the incoming traffic bandwidth approaches its threshold value. And furthermore, the bandwidth should be bounded from the bottom side in order to get a certain traffic class be affected by latencies only within the controlled limits during peak loads. | There are exist two approaches for limiting traffic for each class: to limit the maximum bandwidth that the traffic of corresponding class can occupy, or rely upon the mechanism originally provided by the SSG allowing to borrow bandwidth automatically. In the latter case, the SSG will begin to limit traffic based on classes only when the usage of the incoming traffic bandwidth approaches its threshold value. And furthermore, the bandwidth should be bounded from the bottom side in order to get a certain traffic class be affected by latencies only within the controlled limits during peak loads. |
