PMTUD for IPv4 Multicast - How?

Tue Sep 1 03:47:41 UTC 2015

On Mon, Aug 31, 2015 at 8:55 PM, Masataka Ohta
<mohta at 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?