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

From: Stuart Cheshire <[email-masked]>
Date: Fri, 7 May 2004 10:46:39 -0700

Philip Nye wrote:

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

This is statement is asserted without any supporting evidence, and it is 
false.

This is NOT what we need to avoid.

In order to be a good network citizen, we want to minimize the aggregate 
peak load that a large number of hosts may impose on network 
infrastructure, since peak load is what causes loss. This issue only 
arises when there are a large number of hosts probing simultaneously. Two 
hosts, or three, or four or even ten host probing at *exactly* the same 
time is NOT a problem.

The Ethernet collision loss myth has existed for decades. University 
computer science lecturers teach students that it's a myth, but still the 
myth persists in the larger population.

Collisions do not cause loss on Ethernet. They did not on thick coax, 
thin coax, or on UTP.

Pay particular attention to the second paragraph below.

<http://www.postel.org/pipermail/end2end-interest/2001-October/001529.html>

>What Vernon says is quite right and I'll only add that Collision sensing
>and recovery happens in times on the order of 200 uS to a few mS, on
>even extremely highly contended Ethernet segments (many stations ready
>with pkts to send all the time).  This is far faster than Token passing
>(many mS), in any of its forms, as a very pertinent graph from the
>original IEEE 802 standarization simulations shows (it can be faxed to
>anyone who wishes a copy).  This graph is particularly telling in that
>CSMA/CD become better in relation to Token as the number of contending
>nodes increases -- yes, better.
>
>One reason for trying to rid the world of 'collision' myths is that they
>serve as an alarm for how easily misinformation can arise and how hard
>it is to gather peoples' intellects together to stamp the myths out. 
>Confining ourselves to networking, we must be aware that this applies in
>the TCP/IP realm as well.  Back to the LAN realm, which the original IP
>world had no cognizance of, the collision myth, that started as an IBM
>marketing weapon, matured into a switch vendors' scare tactic to sell at
>first cut-through (a bad idea now in disrepute) and later "a segment for
>every node", so that "collisions would no longer occur" -- just pushing
>the problem into provisioning of the switch fabric.  "Caveat emptor" is
>as necessary today as it has ever been.

Ralph Droms wrote:

>If there is no randomization of subsequent probes, there is no point in
>specifying multiple probes.

No, this is false.

We don't assume the ARP probes are the ONLY traffic on the network.

The reason for trying three times is that there may be OTHER brief bursts 
of traffic on the link that overflow the switch buffers (or cause CSMA/CD 
breakdown, etc.) resulting in one or more probes being lost.

In reality, the amount of traffic generated by ARP probing is too low by 
itself to cause switch buffer overflow -- PROVIDING that it is 
distributed over several seconds. Should all the probes be sent in a 
tight bunch, then the chance of switch buffer overflow could become 
non-zero, which is why the initial random delay is useful to eliminate 
that.

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 May 2004 03:21:23 +0700

Date:        Fri, 7 May 2004 10:46:39 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | Collisions do not cause loss on Ethernet. They did not on thick coax, 
  | thin coax, or on UTP.

Of course they don't - that was never the issue, once again, you're
raising and dismissing a strawman.

The problem is packet arrival and the ability of *every* host on the
LAN to handle a packet train of length N - every host because they're
all broadcast packets.   And the same train in the same order every time.

Typically there's at least one host on a LAN that has a fairly small
threshold for N, before packets are dropped - and usually the same
packets every time.    If that host just happens to be the one that
has the same address as the one being probed by the packet that is
lost (on reception, not on the wire) every time, then the protocol
fails.

As Christian said, the implementation already has some kind of RNG
(or PRNG), it has to to calculate the first random interval.  Thus
there's essentially no cost in using it every time (a few extra
calculations, a multiply & modulus usually).   There's a clear benefit,
you don't get the same packet train every time, different packets
get lost each retransmit.    That allows the protocol to work.

Get off this hobby horse, fine a better one.

kre

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 May 2004 21:12:15 -0000

> Collisions do not cause loss on Ethernet. They did not on thick coax, 

I quite thought Ethernet collisions were a thing of the past! it certainly never occurred to me that they would give rise to higher layer packet loss - what has this to do with IPv4LL?

Large numbers of packets arriving simultaneously - or just a few in some of the lightweight devices likely to use IPv4LL - can and does cause packets to be dropped. If the same sequence of packets arrives each time then the same ones are likely to be dropped each time.

Philip

---

From: Ralph Droms <[email-masked]>
Date: Fri, 07 May 2004 17:21:27 -0400

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

And, of course, you're right about my statement concerning multiple probes
and randomization.  The randomization of subsequent probes desynchronizes
just the probe traffic...

- Ralph