# Effect of block size on network congestion?

I am interested in comparing TCP/IP network congestion under two scenarios:

Scenario 1: A large number of senders send messages to a group of receivers

Scenario 2: Same as above except that the messages are batched into blocks

Does Scenario 2 result in less network congestion in much the same way as packing people into buses will reduce congestion on roads vs. if they were travelling in cars?

The point where I am confused is that I have read TCP/IP chops up messages into small packets so even if messages were batched into blocks, when the block is sent, will it get chopped up into many chunks resulting in no net improvement?

• It would depend on the size of the message, the number of messages, the rate they're sent, etc. TCP will manage congestion all by itself, and will probably do a better job than you can, except under specific, controlled conditions. Dec 13, 2019 at 19:23
• let each message be a tweet so 140 characters. let rate be such that 90% of network bandwidth is utilized in case 1. in general let it be r. i need details in an answer please. if there is something the question has left out, feel free to make reasonable assumptions in your answer. Dec 13, 2019 at 19:29
• TCP/IP chops up messages into small packets Not so small. the maximum TCP message size is 64K bytes. The usual TCP segment size on Ethernet is 1460 bytes. Both are much larger than 140 bytes. So if one host is sending several "tweets" to another, you are already batching messages. Dec 13, 2019 at 20:30
• the batch would be 1MB in size. So on one hand you have 140 char tweets @ r. On the other hand you have blocks @ r/k where k = # of messages in a block Dec 13, 2019 at 20:39
• The overhead in a TCP/IP segment is 40 bytes. So if you send one message at a time, you have about 22% overhead. If you send messages in batches, that obviously goes down. You can do the rest of the math. Dec 13, 2019 at 21:05

You can measure or quantify congestion in several ways:

1. as ratio of peak demand bandwidth and available bandwidth
2. as amount / ratio of dropped traffic (roughly the above ratio - 100%)
3. as required amount of buffer space to even out the peaks

Packet-switched networks generally need to divide traffic flows into chunks or packets. Only circuit-switched networks allow for non-packeted flows, congestion in circuit switching means no connection at all can be established.

Congestion can happen anywhere in the path where either the bandwidth is lower than elsewhere or several paths are aggregated.

Does Scenario 2 result in less network congestion in much the same way as packing people into buses will reduce congestion on roads vs. if they were travelling in cars?

Possibly. The difference in moving people by car or by bus (at same speed) is the overhead: a bus takes 3 times the road space of a car but it can move 30 times as many people. By reducing the overhead you use more bandwidth for "user data", increasing the effective bandwidth. You can calculate the differences:

TCP over IPv4 over standard Ethernet moves (up to) user 1460 bytes with 1538 bytes on the wire (TCP overhead: 20 bytes, IPv4 overhead: 20 bytes, Ethernet overhead: 38 bytes). That's an efficiency of 94.2%.

Increasing Ethernet frames to (non-standard) jumbo frames with 9000 bytes MTU moves 8960 user bytes with 9038 bytes on the wire. The efficiency is 99.1%. Accordingly, user data can be transmitted 4.4% faster using the same bandwidth.

If you don't send a large stream but only 100 bytes at a time, you increase the overall overhead significantly: 100 bytes user data in a 178 byte frame drops the efficiency to 56.1%.

As you can see, trying to decrease congestion by increasing frame/packet size above a certain amount doesn't do much. Apparently, Ethernet is already using busses. However, you should make sure that packets use the maximum size to avoid unnecessary overhead and - potentially - congestion. You won't want to have a road filled with Alfa Spiders.

Of course, you could also use UDP instead of TCP if you don't require automatic retransmissions and arbitrary chunk sizes, reducing the overhead by 12 bytes per message.