On 27-jul-2007, at 15:08, John Heffner wrote:
The router is different because it must generate ICMP PTB messages with the correct next hop MTU. There's no way for the router to do 4821 like hosts can.
Yes, it seems you are correct. I was about to say that you can even easily have hosts with different MTUs on the same subnet without trouble if there are no routers on the subnet, but that's not entirely true: I think that A/V streaming happens with < 1500 packets anyway, but EDNS0 has the potential for packets > 1500 bytes without the ability to recover from MTU mismatches, and traditional NFS with 8k UDP packets certainly has that problem. But we tend to have routers on our subnets anyway.
However, if you consider the case of subnets used by multiple routers with different MTU sizes, and the fact that RFC 4821 isn't universally deployed, then a way to learn the maximum MTU between any two routers would be very useful. This way, the routers can generate the appropriate packet too big messages.
One thing to note is that if you imagine a world where the vast majority of hosts with large MTUs use 4821, it may be operationally acceptable to deliberately break classical pmtud by not generating ICMP PTB messages.
Why would you want to do that? Even with full RFC 4821 support regular PMTUD is still extremely useful because it gives you the exact value of the path MTU immediately after sending an oversized packet.
It's not what I would want in an ideal world. However, if other solutions don't materialize, this is one possible avenue of evolution. Attacking the problem in multiple complimentary ways is always a good thing. :)
I still don't see how deliberately breaking classical PMTUD is helpful...
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
