On Mon, Aug 31, 2015 at 8:55 PM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Chris Marget wrote:
I'll probably come around, but I've not yet concluded that "screw it, fragment my traffic, I don't care" is the stance that a conscientious application should be taking.
Don't you care, for routers, generating ICMP PTB is as burdensome as generating fragments?
I don't think so. If PMTUD is working (big IF, I know),
Yup.
the ICMP PTB generation is a one-time thing (or once per 10 minutes or whatever)
A meaningful interval of retry is not 10 minutes but RTT measured at layer 4 or above.
I took the 10 minute value from RFC1191's recommendation about when it's appropriate to try larger MTU sizes. One ICMP message should hold the sender off for 10 minutes (or whatever), just like it does with unicast traffic. Would you explain why a router might need to generate ICMP PTB at a rate corresponding to intervals of RTT? I don't see why the error rate would be correlated with path length. Anyway, RTT isn't something that necessarily exists with multicast applications.
Is the concern that I might DDoS myself
Or, with spoofed source addresses, someone else.
The latter concern isn't unique to this case and applies to many (most? all?) types of reflection attacks. Indeed, many other protocols have disabled potentially useful features in order to thwart reflection attacks which rely on spoofed source addresses. At least in the case of those protocols, we have the choice to enable monlist, ip_respond_to_echo_broadcast or whatever as appropriate for the environment. I'm still not sure where this leaves the application which wants to do the right thing. - Send 1500 byte frames and expect fragmentation? - Guess at the least of all likely path MTUs? - Send 576 byte frames? - Build a feedback mechanism into the application?