1

MTU (Maximum transmission unit) is the maximum frame size that can be transported. When we talk about MTU, it's generally a cap at the hardware level and is for the lower level layers - DataLink and Physical layer.

Now, considering the OSI layer, it does not matter how efficient are the upper layers or what kind of magic-sauce they are applying, data-link layer will always construct frames of size < 1500 bytes (or whatever is the MTU) and anything in the "internet" will always be transmitted at that frame size.

Text

Does the internet's transmission rate really capped at 1500 bytes. Now-a-days, we see speeds in 10-100 Mbps and even Gbps. I wonder for such speeds, does the frames still get transmitted at 1500 bytes, which would mean lots and lots and lots of fragmentation and re-assembly at the receiver. At this scale, how does the upper layer achieve efficiency ?!

[EDIT]

Based on below comments, I re-frame my question:

If data-layer transmits at 1500 byte frames, I want to know how is upper layer at the receiver able to handle such huge incoming data-frames.

For ex: If internet speed in 100 Mbps, upper layers will have to process 104857600 bytes/second or 104857600/1500 = 69905 frames/second. Network layer also need to re-assemble these frames. How network layer is able to handle at such scale.

DUDE_MXP
  • 724
  • 7
  • 24
  • Not quite sure why an MTU of 1500 bytes (assuming that's the case) would prevent 10-100 Mbps throughput? It just means that every 1500 bytes the network device pumps out a new header, which is a slight overhead. But it can still pump out the data and those headers at ~100 Mbps. – deceze Oct 28 '20 at 07:42
  • yes, but my main question was about efficiency. How is this a slight overhead - 100Mb is 104857600 bytes. That would mean processing 104857600/1500 = 69905 frames/s. The network interfaces will have to send 69k frames/s and the receiver needs to re-passable the same 69k frames every second. This does not sound sligh-overhead to me. – DUDE_MXP Oct 28 '20 at 07:51
  • Yes…? It's still an overhead in the 1-2% range. The advantage of smaller packets is that it requires less retransmission for failed packets. So on congested routes, smaller packets can lead to more overall throughput. – deceze Oct 28 '20 at 07:55
  • 1
    OSI has nothing to do with the Internet: it is a model whose only purpose was to describe the more or less defunct OSI protocol suite. MTU is a property of the data-line layer: it has little or nothing to do with throughput. – user207421 Oct 28 '20 at 09:19
  • Your concern is that the network hardware shouldn't be able to process 69905 frames per second? Assuming you'd use an MTU of 100Mb, so you only need to transmit one packet per second… you're not wondering about processing 100Mbps at all, but somehow the same volume split into 69905 frames *is* a problem? – deceze Oct 28 '20 at 13:42
  • @deceze yes, same volume split up is a problem. And my main concern is does the receiver really processes 69905 frames every second, if so how is it even able to achieve it ?! I just wanna make sure this is what happens on internet or am I missing something. – DUDE_MXP Oct 28 '20 at 15:37
  • Why *shouldn't* it be able to achieve this? 69k things per second really isn't that much. Do you know how insanely fast modern computers are? Especially when you throw dedicated hardware at the problem? https://en.wikipedia.org/wiki/Network_interface_controller#Performance_and_advanced_functionality – deceze Oct 28 '20 at 15:44
  • What makes you think the rate-determing step is the frame rate rather than the total bandwidth? – user207421 Oct 28 '20 at 23:46
  • Mbps are megabits not megabytes per second. So, there are only 8378 frames per second need to be processed for 100Mbps connection. – gudok Oct 31 '20 at 08:25
  • In general, you should not care about number of frames. Any data is sent for a reason, and thus should be processed at the application level: stored on a disk, displayed, etc. Unless your MTU is some ridiculously small value (couple of bytes), the application layer will be the bottleneck. – gudok Oct 31 '20 at 08:30
  • The issue of small frames happens usually only in high-load servers. In this case there are number of techniques to reduce the overhead: jumbo frames, frame coalescing, large send/receive offload. – gudok Oct 31 '20 at 08:34
  • By the way, I found a question and answer (my answer) that explains both TCP segmentation and IP fragmentation. – Ron Maupin Nov 04 '20 at 23:56
  • @RonMaupin Can you please share the link ? – DUDE_MXP Nov 05 '20 at 03:46
  • Sorry, [yhis is it](https://networkengineering.stackexchange.com/q/70046/8499). – Ron Maupin Nov 05 '20 at 10:58

1 Answers1

1

If data-layer transmits at 1500 byte frames, I want to know how is upper layer at the receiver able to handle such huge incoming data-frames.

1500 octets is a reasonable MTU (Maximum Transmission Unit), which is the size of the data-link protocol payload. Remember that not all frames are that size, it is just the maximum size of the frame payload. There are many, many things with much smaller payloads. For example, VoIP has very small payloads, often smaller than the overhead of the various protocols.

Frames and packets get lost or dropped all the time, often on purpose (see RED, Random Early Detection). The larger the data unit, the more data that is lost when a frame or packet is lost, and with reliable protocols, such as TCP, the more data must be resent.

Also, having a reasonable limit on frame or packet size keeps one host from monopolizing the network. Hosts must take turns.

For ex: If internet speed in 100 Mbps, upper layers will have to process 104857600 bytes/second or 104857600/1500 = 69905 frames/second. Network layer also need to re-assemble these frames. How network layer is able to handle at such scale.

Your statement has several problems.

First, 100 Mbps is 12,500,000 bytes per second. To calculate the number of frames per second, you must take into account the data-link overhead. For ethernet, you have 7 octet Preabmle, a 1 octet SoF, a 14 octet frame header, the payload (46 to 1500 octets), a four octet CRC, then a 12 octet Inter-Packet Gap. The ethernet overhead is 38 octets, not counting the payload. To now how many frames per second, you would need to know the payload size of each frame, but you seem to wrongly assume every frame payload is the maximum 1500 octets, and that is not true. You get just over 8,000 frames per second for the maximum frame size.

Next, the network layer does not reassemble frame payloads. The payload of the frame is one network-layer packet. The payload of the network packet is the transport-layer data unit (TCP segment, UDP datagram, etc.). The payload of the transport protocol is application data (remember that the OSI model is just a model, and OSes do not implement separate session and presentation layers; only the application layer). The payload of the transport protocol is presented to the application process, and it may be application data or an application-layer protocol, e.g. HTTP.

The bandwidth, 100 Mbps in your example, is how fast a host can serialize the bits onto the wire. That is a function of the NIC hardware and the physical/data-link protocol it uses.

which would mean lots and lots and lots of fragmentation and re-assembly at the receiver.

Packet fragmentation is basically obsolete. It is still part of IPv4, but fragmentation in the path has been eliminated in IPv6, and smart businesses, do not allow IPv4 packet fragments due to fragmentation attacks. IPv4 packets may be fragmented if the DF bit is not set in the packet header, and the MTU in the path shrinks smaller than the original MTU. For example, a tunnel will have a smaller MTU because of the tunnel overhead. If the DF bit is set, then a packet too large for the MTU on the next link, the packet is dropped. Packet fragmentation is very resource intensive on a router, and there is a set of steps that must be performed to fragment a packet.

You may be confusing IPv4 packet fragmentation and reassembly with TCP segmentation, which is something completely different.

Ron Maupin
  • 6,180
  • 4
  • 29
  • 36