On 31-jul-2007, at 23:40, Fred Baker wrote:
On Aug 1, 2007, at 5:01 AM, Iljitsch van Beijnum wrote:
Rethinking the type of MTU detection packets: a new mechanism that
must be supported by both sides, or something that can be
implemented by just one side?
see previous note. I don't think the mechanism has to even be known
to both sides necessarily, just observable by the side that needs
the answer.
Right. My conclusion was also that having a one-sided mechanism is a
good start.
But adding some extra logic that allows two sides to determine the
maximum size they both support, including the situation where one end
doesn't support jumboframes, without unnecessary test packets, is
also helpful in addition to that.
One way to implement RFC 4821 would be to literally send each of
the enumerated segment sizes in the first burst (send n segments,
of sizes 9000, 8192, 4096, 2048, 1500, 1460, 1400, and 1280, and
see how much data is acknowledged in the first acknowledgment).
When you have RFC 4821, life is simple. :-)
However, off the top of my head I can think of two UDP applications,
one that absolutely uses large packets (NFS over UDP), and another
that could in the future (DNS with EDNS0 in the presence of IPv6
roots and/or DNSSEC) that would fail badly by simply setting the MTU
to "jumbo" and letting RFC 4821 take care of the difference.
And routers don't know about RFC 4821 so they necessarily have to be
more conservative than RFC 4821 compliant hosts, and with a router
with a 1500 byte MTU in the middle life isn't exactly jumbo-sized.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
