Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly

From: Stuart Cheshire <[email-masked]>
Date: Fri, 7 May 2004 15:57:52 -0700

>Stuart - can you explain which "collision myth" is referred to
>in the second paragraph.  I think there are several.

The unstated unconscious assumption in so much of the discussion on this 
mailing list that, if two machines send packets at the same time, then 
inevitably one or both get lost.

If you re-read past discussion you'll see that it's never stated, but 
almost always assumed. To pick one recent example:

>the chance we need to avoid is that
>you and I both agree on ALL FOUR values in our series

Why do we "need" to avoid this?

The assumption behind that statement, and so many like it, is that it 
would be a catastrophe if two machines were to send at the same time, and 
consequently the protocol needs extra mechanisms to avoid this 
catastrophe. This assumption is felt to be so self-evident that it is 
never stated explicitly, just assumed as a universally accepted axiom.

The fact is that spreading the first packet uniformly over a one-second 
interval offers a dramatic benefit by eliminating a potentially large 
synchronized burst. The faulty logic is to conclude from this, "If some 
randomness is good, then more randomness must be better, right?"

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 May 2004 08:24:11 +0700

Date:        Fri, 7 May 2004 15:57:52 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | The unstated unconscious assumption in so much of the discussion on this 
  | mailing list that, if two machines send packets at the same time, then 
  | inevitably one or both get lost.

Not two, two packets at the same time will almost never be "lost".
Three on the other hand is a different issue entirely.   Have three
packets sent "at once" and some recipients I can guarantee you will
fail to receive the one of them.

  | The fact is that spreading the first packet uniformly over a one-second 
  | interval offers a dramatic benefit by eliminating a potentially large 
  | synchronized burst.

It changes one huge burst into a bunch of smaller bursts.   The problem
only goes away if you can somehow guarantee that the smaller bursts will
be small enough (< 3 packets) or won't be repeated (so it does no real
harm if the 2nd or 4rd packet of a burst is always lost).

[From another message]

  | Complete nonsense. Of course it doesn't fail. All this posturing ignores 
  | the fact that WE'VE BEEN SHIPPING PRODUCTS FOR SIX YEARS.

On exactly how many crappy ancient ISA ethernet controllers?
And on networks with such hosts and how many thousand nodes,
all powering up at the same time?   And tested how often?

And now you're resorting to proof by "I haven't seen it fail" ?
And ignoring other people who are telling you they have seen these
kinds of failures?

  | In the vanishingly unlikely event of repeating 
  | identical packet loss, the conflict is subsequently detected and resolved 
  | a few seconds later when subsequent ARP packets are sent, and the hosts 
  | then pick new addresses and immediately re-probe.

And you know that subsequent ARP packets will be sent that soon just how?

You're presuming that (at least) one of the hosts is going to want to
send packets (soon) - what if they're both passive receivers?   Then people
trying to talk to them notice the conflict, when they arp for the
address and get two replies, but just how do the hosts in question
ever notice anything untoward?   They each get all the ARP info they
ever need in the ARP queries that seek their MAC addresses.

  | I'm not trying to propose any radical new things here. I thought draft-07 
  | was pretty good. My concerns are all the weird stuff that's appeared 
  | since then that no one can really justify, except with answers like, "I 
  | think someone else wanted it."

Whatever you might have thought about draft-07, that isn't the one that
went through IETF last call, and was approved by the IETF.   You might have
liked it, but clearly lots of other people didn't.    07 was a LONG time
ago now.   There has been lots of debate over lots of these issues in the
intervening period - much of whioch you participated in.   Some of those
ended in outcomes that you obviously don't agree with.    Live with it.

The "I think..." is an incorrect summary of what was said about one
particular issue, which was really "requested by the IESG".  That
text was basically noise as best I could tell, we could delete it, then
the IESG would just say to put it in again.   If your objective is to
delay this doc forever, going round and round that circle would certainly
do it.   Most of us would prefer to have the thing published, and if the
price of that is to include one meaningless noise sentence, to pacify
some part of the IESG, then I think we can survive - that's much less
that some other WG's have to do to get some docs past the IESG approval
process.

kre