On 4-aug-2007, at 0:27, Templin, Fred L wrote:
I like the spirit of your text, but the problem I have with it is that it doesn't say how the application can discern loss due to an MTU restriction from loss due to, e.g., congestion.
I strongly disagree here. PMTUD isn't something that should happen in applications. It's easy to get it wrong, and applications tend to stick around for a LONG time.
I believe all Joe was saying was that an application that can discern MTU-related loss (with or without explicit indications from the network), and has a way to reduce the size of the messages it sends, should probably do so.
I know what he said; I disagree. As a rule, application developers have very little understanding about network issues, and as a second rule, they _think_ they know a lot more than they do. The potential for harm here is many times larger than the potential for good.
Applications that use UDP or other transports that can't implement RFC 4821 should clear the DF bit in IPv4 so that fragmentation can happen as needed. Anything else will cause breakage.
Any application can clear DF in the packets it sends and hope that the final destination has a large enough buffer to reassemble any fragmentation that occurs in the network.
The latter is not a consideration: regardless of whether the DF bit is set to cleared, if packets are larger than what can be reassembled AND fragmentation is required, no communication is possible.
But, it would be well advised to try to ascertain the reassembly buffer size first - unless it has some way of knowing or guessing this in advance.
There are only two sources of this knowledge: talk to the other side (as in DNS EDNS0) or the value is listed in the relevant RFC. No guessing PLEASE. This is important: if you guess, you will guess wrong a significant part of the time. If you can't know that you're going to do it right, at least do it wrong consistently (i.e., fixed value in an RFC) so operators can work around it.
By: "MRU", I mean the same thing as for "EMTU_R" (Effective MTU to Receive) per ([RFC1122], Section 3.3.2).
To me, that's not what "MRU" means. Also note that the same 18-year- old RFC tells us that a hardcoded limit is bad here.
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
