Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

[Ted Lemon <[e-mail]>]

On May 7, 2014, at 1:51 PM, Bernie Volz (volz) <[e-mail]> wrote:
> Here's some documentation from IBM (google found this - 2nd in list when searching for IPV6_USE_MIN_MTU):

Ah, thanks.   That took so long to load when I tried it that I gave up, but I waited this time and got the info.

I think this option is not only unnecessary, but harmful, when used with DHCP, because it sets the maximum DHCP message size to 1280 when in nearly every conceivable circumstance, the path MTU will be at least 1500.

The reason why you might want to enable this option for DNS is that you really care about latency on DNS queries, and waiting for PMTU discovery increases latency.   No such problem exists for DHCP: the initial packet is _always_ multicast by the client, and that's the only one where we care about latency.   There's no latency for the client because it knows the path MTU--it's the link MTU.   There may be occasional latency on the relay agent, but it is amortized over many clients, and hence not really a problem.   It's unlikely that the same client will pay the latency tax twice.

Unicast queries only happen at renewal time.   At renewal time, latency is immaterial: you already have a configuration―you're just refreshing it, so nothing is blocked waiting on the response.

So I see no beneficial use case for this, and many harmful use cases.   We should be advising implementors _not_ to use this option, not advising them _to_ use it.