4 ms·
>"Imagine, for a second, that you are trying to keep up with a 100Gb/s network adapter. As networking developer Jesper Brouer described back in 2015, if one is
by bogomipz 5y ago
>"Imagine, for a second, that you are trying to keep up with a 100Gb/s network adapter. As networking developer Jesper Brouer described back in 2015, if one is using the longstanding maximum packet size of 1,538 bytes, running the interface at full speed means coping with over eight-million packets per second."
Should this not be "frame size" instead of "packet size"? Unless I am reading this incorrectly the maximum TCP packet size is 1500(20 bytes for IP header, 20 bytes for TCP header and 1460 bytes for the actual payload.) I'm not trying to be pedantic but the other 38 bytes would all be considered part of the Ethernet and not TCP no?
- eklitzke 5y agoThis is wrong for a few reasons. It is common to try to fit TCP packets into 1500 bytes (minus the bytes for the IP and TCP headers) because 1500 bytes is a common MTU for Ethernet, but this isn't a limitation of TCP, it's just something done to avoid fragmentation. Without extensions TCP packets can be sized up to 64KB. For example, in an environment with jumbo Ethernet frames you might have 9000 byte MTU at the link layer which is just fine. But it's also fine to send a 9000 byte or even 64KB TCP packet over a network with a 1500 byte MTU, the packet will just be split up at the IP layer using IP fragmentation. And as the article points out, RFC 2675 allows creating TCP packets whose payload is even larger than 64KB.
- bogomipz 5y agoNo it is not wrong. In fact you are supporting my point exactly. My question was about the terminology the author was using. Packets are TCP terminology. Frames are ethernet terminology and the 1500 byte limit is because this is the MTU of an Ethernet interface, again a layer 2 concern not layer 4. See also elsewhere in this thread where I also asked what the benefit of this over Jumbo frames.