Re: draft-van-beijnum-multi-mtu-05.txt

[David Lamparter <[e-mail]>]

On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote:
> On 4/6/16 12:18 PM, David Lamparter wrote:
> > On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote:
> > Ok... easy comments/opinions first:
> > - should definitely be ICMP, not UDP.  Erik Nordmark's suggestion to
> >    piggyback on NUD sounds great, though admittedly I haven't thought it
> >    through looking for pitfalls.
> One issue compared to a dedicate probe is that a NUD (a unicast NS) of 
> size X wouldn't necessarily result in a unicast NA that is also padded; 
> perhaps one can add such behavior so that we can get the bidirectional 
> probe in both directions.

That might be (half of) a feature: if the MTU probe is a NS option, and
the target host does not support it, we still get a NA reply.  That's
better than timing out waiting.  The downside is that a NA without the
"MTU response" option doesn't mean that the host doesn't implement the
protocol -- the NA could be in response to something else.

That said, I'd expect the probability of a host ignoring a new NS option
is much lower than it filtering out unknown new ICMP (sub)types or UDP
ports.  If that reduces useless probing (or even waiting), I'm all for
it.

(As I understand it, the draft in no case suggests waiting for the
probes to come back, so it's not much of an argument.  Might still
reduce useless probe traffic?)

> > - there's probably a lot of 4821 that can be incorporated by reference,
> >    shortening the draft by quite a bit
> Are you referring to the choice of sizes to try? I haven't re-read 4861 
> next to this draft.

I was thinking it could be possible to inherit parts of the algorithm
and corner case behaviour spec, but the draft makes the argument that
its probing can be much more aggressive since there is (almost?) no
congestion interference.  That seems a fair point, so I guess I spoke
too quickly :(

> > - if possible (not sure on NUD interactions), this should use RFC5082
> >    TTL security, sending HL=255 and discarding packets !=255
> Yes, it would make sense to use the TTL security approach for the probe
> protocol, whether it is UDP or NUD or something else.

Rereading the draft, it already says "other than 255 [...] discarded".
So my comment turns into "add explicit reference to 5082".


-David