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

["Bernie Volz (volz)" <[e-mail]>]

Ted:

1. There is client unicast. Though not sure how much it is used.
2. From my understanding (at least from the IBM documentation), if the destination is local to link (i.e. client multicast), the link's MTU is used (not the min MTU). So this still benefits client multicast and most of the communication in DHCPv6 to use the FULL link's MTU.

So the only case is when the next hop (again, either relay<->relay or relay<->server or client/server unicast cases where the next-hop isn't local to the link), will the 1280 MTU be used and result in fragmentation.

I don't know who well PMTU works these days for UDP and how widely it is implemented in the common stacks. If it works great, then maybe this option is unnecessary (as the components must likely to need them are probably on 'good' stacks - relays and servers that implement PMTU).

I am taking a sample of one (the IBM documentation) and perhaps there is other information that says this option doesn't work well.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Wednesday, May 07, 2014 3:08 PM
To: Bernie Volz (volz)
Cc: dhcwg; 神明達哉; Ralph Droms
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

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.