LAN – Why Torrent Traffic Creates Greater Congestion Than Regular Traffic

congestionlanqos

For simplicity let's assume that we have very simple LAN. There is some router with uplink to the internet. To this router there is connected some basic 24 ports switch, and from that switch there are cables going out to few workstations in a office.

The link from the LAN to the internet is 10mbps download, 2mbps upload. If workstation1 will start downloading data from a website (client-server) with a speed of 5mbps, or 625kBps (since 5 megabits equals 625 kilobytes), will the connection for other people working in a office, on other workstations be better than in the case, where workstation1 is downloading data from torrent client, with the same speed of 5mbps, but from multiple peers, not from one source as is the case in downloading from website?

Does it have anything to do with the fact that in peer-to-peer you have multiple connections?

If in case of torrent traffic the quality of connection will be worse for other users, then how it will be worse? Will it just increase latency, or will it also worsen downloading speed, increase jitter?

And last questions, what are the ways to control side effects of people using p2p for example in small/medium office with one simple LAN?

My explanation of the question may not seem professional, but please use technical terms, I am not looking for "explain it like I am 5 years old" 😉 I have quite good understanding of networking, routing, congestion control and protocols etc (at least I think so).

Best Answer

If workstation1 will start downloading data from a website (client-server) with a speed of 5mbps, or 625kBps (since 5 megabits equals 625 kilobytes), will the connection for other people working in a office, on other workstations be better than in the case, where workstation1 is downloading data from torrent client, with the same speed of 5mbps, but from multiple peers, not from one source as is the case in downloading from website?

Anything that monopolizes the WAN bandwidth will affect all other users need to use WAN bandwidth. Each peer that the torrent user is receiving from will try to send as much data as fast as it can.

Does it have anything to do with the fact that in peer-to-peer you have multiple connections?

The problem is primarily that the torrents are filling you bandwidth in both directions, monopolizing your WAN.

If in case of torrent traffic the quality of connection will be worse for other users, then how it will be worse? Will it just increase latency, or will it also worsen downloading speed, increase jitter?

Anything that fills your bandwidth, including torrents can cause latency and jitter, and interfere with your normal business operations.

And last questions, what are the ways to control side effects of people using p2p for example in small/medium office with one simple LAN?

One option is to block torrents on the firewall, but this can be difficult to keep up with, and it depends on your company's policies to allow/disallow such things. Many companies consider this stealing of company resources; it does cost a company money to provide the bandwidth for this.

If you can't block the torrents, then this is the perfect case for QoS. QoS is all about fairness, as the network administrator defines it. QoS is a topic too large to go into detail here, but I will cover some points. You may want to hire a consultant who can analyze your traffic and develop a solid QoS policy for you.

To properly implement QoS, you need a comprehensive set of QoS policies that are consistently implemented across your network devices. You want to mark the traffic as close to the source as possible, usually on the access switches. Many access switches will simply mark all traffic as BE unless configured otherwise or for trust.

You would set up policing, shaping, and queuing on your routers. Most traffic is fine to be marked as BE. You want real-time protocols, e.g. VoIP marked as EF and placed in priority queues with policing. Bulk type traffic, e.g. server backups, torrents, etc., should be placed in lower priority queues.

There are also techniques like RED that will randomly drop packets in queues to prevent the queues from filling and doing tail-drop, which can cause TCP global synchronization (very bad, causes queues to alternately fill then starve).