Yes, that's true. very good discussion. I bring this up since you can do whatever you want on a point to point link. For maximum compatibility, using 1500 or 1518 will help you handle all of the cross-network cases where you cross a bridge/switch or gateway.
The other unintended side-effect of this is that when you use these smaller MTU's you will impose a slightly larger number of packets in overhead. Many people think the bitrates are the limitation but it usually ends up being the number of packets. What you put in your payload is going to mandate your fragmentation and therefore your true number of packets to/from your stack. Its time or space, you can't have both :-) On Thu, Mar 4, 2021 at 6:38 PM Johnny Billquist <b...@softjar.se> wrote: > On 2021-03-05 00:21, Gregory Nutt wrote: > > > > On 3/4/2021 4:59 PM, James Dougherty wrote: > >> Thank you, that is interesting. Doesn't it also imply is that with the > >> smaller MTU of 590 you'll end up having > >> fragmentation which will add a little bit of processing overhead? I > >> understand it is not that big of a deal since > >> fragmentation happens a lot, but for the best performance yes, both > sides > >> have to agree on a decent MTU. > > > > In TCP, both sides do agree. That is the negotiated MTU. > > Sorry for jumping in like this. Stop me if I bore people too much. > > Actually, TCP do not negotiate any MTU. > > But there are two mechanisms that is sortof close to this, which might > be what you are thinking of. > > The first one is MSS. This is a value each TCP endpoint announce to the > other end, and which essentially declares the largest packet size that > end is capable of handle (well, primarily receive). Each side just sends > the MSS that applies for that size. And each side should not send > packets that are larger than MSS the other end declared. And usually you > would not send packets larger than your own MSS, since usually there is > some good reason for whatever MSS you declare to the other end, and it > applies just as much to transmission as reception. > > That means you'll commonly not see packets larger than the smaller MSS > of the two ends involved in communication. > > However, this does not avoid packet fragmentation happen, because packet > fragmentation is an IP level feature, and it will also happen if any hop > between the two endpoints have a small enough MTU, or possibly if > various IP options are added that TCP just don't know about, and so on. > > So, the second mechanism is the path MTU detection (or PMTU). But this > is no negotiation at all, but a trick the sending TCP do in order to try > and figure out how large packets can be sent without them being > fragmented along the way. The basics of the trick is that TCP sends > packets with the don't fragment bit set in IP, and if any hop along the > way require the packet to be fragmented, an ICMP error packet will > instead be returned. This is then a signal to TCP that it should > retransmit, but also reduce the PMTU. And once it a while, TCP should > try to increase the PMTU, to just check if the path might actually have > changed to allow larger packets (assuming you're not already at your own > interface MTU, at which you can't go larger anyway). > > And as to MTU, the actual "legal" lower limit of the MTU in IP is 68. > However, the minimum sized packet an IP implementation must support is > 576 bytes. But there is nothing saying that it has be able to be > transferred without fragmentation. But an IP stack is technically > allowed to drop without notice packets that are larger than 576 bytes > (although it wouldn't be very nice). > > If people want to read all the itty bitty details, I can give you the > RFCs. But you can just google it as well. > > > Of course, larger MTUs have better transfer rates. That is the old > > performance vs. size trade-off. If so configured, both end points > > should use the configured MTU of the network. However, they should also > > work with limited devices with smaller MTUs. > > All very true. But it does mean that if you are on the same ethernet, > and one host have defined a smaller MTU, and you use UDP for example, > then larger packets might get lost without any feedback. Because UDP > have no clue about the other end having a different/smaller MTU. > > TCP should usually manage, since MSS should reflect the local MTU, and > thus the other end knows it can't send larger packets than that, when > using TCP at least. > > It's rather recommended that all hosts on a shared medium use the same > MTU, if possible. Otherwise there is a clear risk that communication > might not work as expected. > > Johnny > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol >
