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
