On Jan 14, 2010, at 7:58 AM, Patrik Fältström wrote: > > Please do not start talking about enforcing some fixed limit that we will > laugh about 10 years from now... And if you talk about a limit, pick > something very large (like 65535 that seems to be already chosen). > > It is enough problems with the 512 limit of today. I do not want to have the > same problems when we pass 4096. > > Implementations should be free to choose an implementation limit smaller if > they want to (and signal that in the EDNS0 size), but please do not say that > "max value on EDNS0 size will forever be 4096" or something similar. > > Be careful with the wording...
Except that EDNS0 MTU is closely coupled with the UDP protocol and its unreliable nature: this message MTU is irrelevant for TCP or another reliable protocol. It is highly unlikely that the network's MTU will expand beyond 1500B: There is too much Ethernet, and >1500B MTUs don't really benefit things anyway, because the overhead reductions of going to a higher MTU are near zero (Amdahl's law). Which means the number of fragments which ALL need to be received correctly goes up linearly with the size of the message. Even WITH a larger MTU, bit-errors become more common. So, even at a minimum, you'd expect many more failures, dropped packets, etc, with a 40,000B datagram than a 4000B datagram. And DNS over UDP is already unreliable enough, at least when you consider it all the way to the end host with a reasonable timeout on lookups. Thus given the nature of the UDP protocol, it is highly unlikely that you'd ever want to do ~10K+ byte UDP datagrams. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
