Subject: Re: my response to the proposed changes

From: Stuart Cheshire <[email-masked]>
Date: Thu, 24 Jun 2004 11:46:37 -0700

>That is what I mean by holding onto one's address.  The only point where
>I think we disagree is that the *text* for WATCH_WAIT is the same as for
>DEFENSE_INTERVAL in section 9.  Since both are set at 10 seconds
>presently, we are really only disagreeing over which version of the text
>is clearer, right?
>
>Best regards,
>
>Erik

I'm just puzzled by the choice of the term "WATCH_WAIT" for the 
ten-second time constant.

It implies that you're watching for ten seconds for something (you're not 
-- you're *always* watching for conflicting ARPs) or that you're waiting 
for ten seconds for something (you're not -- there's no waiting).

To emphasize that there's no waiting or any other disruption to normal 
operation, the draft even spells this out explicitly:

   Having done this, the host can then continue to use the address
   normally without any further special action.

The whole point of this text was to explicitly state that there's *no* 
need for the host to stop what it's doing, and wait for ten seconds 
watching to see if there's another conflicting ARP, before it can resume 
normal operation. Normal operation continues without interruption. 
Calling the constant WATCH_WAIT kind-of undermines that message.

The ONLY relevance of the ten-second time constant is that it imposes a 
rate-limit on the frequency of defensive ARPs that are allowed, to 
prevent storms. Sensible names might be:

  DEFEND_INTERVAL
  MINIMUM_DEFEND_INTERVAL
  DEFENSIVE_ARP_RATE_LIMIT
  RETALIATORY_ARP_RATE_LIMIT
  MANDATORY_RECONFIGURE_WINDOW
  ... and so on.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 25 Jun 2004 10:00:27 +0100

I believe Stuart is arguing about names and whether they suggest the right thing in the minds of the reader - not about algorithms.

The name "DEFEND_INTERVAL" is used in the current draft in section 2.2.1. (There is a proposal to change this name to ANNOUNCE_WAIT). For this reason re-using "DEFEND_INTERVAL" for what is currently WATCH_WAIT is a bad idea however apt the name might be since it is obviously leading to huge confusion.

Stuart says of WATCH_WAIT:

> prevent storms.

Not the only relevance - this period defines a frequency of conflict above which a host is obliged to stop defending and find another address. This goes beyond storm prevention and defines a practical test for whether an existing address is tenable.

> Sensible names might be:

Try "DEFENSE_WINDOW" - it's snappier.

I support Stuart's assertion that WATCH_WAIT is not a good term. For the reasons above, I do not support the use of DEFDEND_INTERVAL for anything.

Philip

---

From: Robert Elz <[email-masked]>
Date: Fri, 25 Jun 2004 18:07:13 +0700

Date:        Fri, 25 Jun 2004 10:00:27 +0100
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <005701c45a92$dc3f2f70$131010ac@aldebaran>

  | Try "DEFENSE_WINDOW" - it's snappier.

If you're going to do that, at least spell it rationally

	DEFENCE_WINDOW

(or avoid US vs English wars, and simply use a different word).
Using "window" is good though, that suggests the correct properties.

And since I'm here (I was going to avoid this discussion), I certainly
agree that preventing dueling ARPs at flat out net rate is a good
thing to do), but I cannot fathom any justification for 10 minutes
as the timeout, 1 minute would be just as good, even one second would
be adequate for that purpose (2 ARP packets a second might not be
wonderful, but it isn't going to kill any network, and is unlikely to
occur very often in any case).

It looks to me as if this number is a reaction to "I have seen very bad
things happen with no limit here, and so we must prevent that" (which is
fine) but then going to extremes to make sure nothing like the "bad things"
can possibly happen, ever, way beyond what is actually required, or reasonable.

Beyond that, I am still yet to see any justification for requiring hosts
to give up their address after receiving 2 ARPs in the window?  (Remind me,
must they be from the same host, or would 2 from anyone do it - if the latter,
the window should be made a small as reasonable, not as large.)

Suggesting that as a good thing to do is fine, but why require it?

If we have 2 hosts, and they have this conflict, then there are
3 possibilities

both abandon the address & acquire new
		That's the current expectation in the draft
		(no need to say more about it here)

one of the hosts abandons its address, the other continues using its
		Everything works fine, the host that wanted to keep its
		address continues as if the conflict had never existed,
		the other acts just the way the draft currently expects.
		No problem.

both choose to retain the conflicting address
		In this case, both hosts are screwed, and most likely
		neither can talk.    But that's what they have chosen as
		an option - better to prevent the address being used by
		a potential interloper, than to worry about keeping its own
		network operations functional.
		Also fine (it's the host's choice - and no harm comes to
			the rest of the network).

So, why are we requiring hosts to abandon their address in the case
of a conflict again?

kre

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 25 Jun 2004 12:11:33 +0100

> From: "Robert Elz" <[email-masked]>

> If you're going to do that, at least spell it rationally

OK by me.

Philip