On Tue, 2005-09-27 at 10:06, Robert Elz wrote:
> Date: Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
> From: Dean Anderson <dean@xxxxxxx>
> Message-ID: <Pine.LNX.4.44.0509261531270.32513-100000@xxxxxxxxxxxxxx>
>
> | It is not DNSSEC that is broken.
>
> I have not been following dnsop discussions, but from this summary, there
> is nothing broken beyond your understanding of what is happening.
It's worse. The reasoning is broken on other points, as well.
In these arguments, RFC 1812 has been cited repeatedly as a
specification for load-splitting. By my reading, 1812 is extremely
vague about the topic, and does not require a specific spreading
algorithm. Its strongest recommendation is that there be a way to turn
it off if it doesn't work for you, which should by itself be a clue that
load-spreading should be used with caution; it also cautions that that
load-splitting was an area of active research at the time 1812 was
published.
Moreover, load-splitting which results in the sort of flow-shredding
which would disrupt multi-packet anycast exchanges also causes
significant difficulties for unicast. To quote from rfc2991 section 2:
Several router implementations allow multipath forwarding. This is
sometimes done naively via round-robin, where each packet matching a
given destination route is forwarded using the subsequent next-hop,
in a round-robin fashion. This does provide a form of load
balancing, but there are several problems with approaches such as
round-robin or random:
Variable Path MTU
Since each of the redundant paths may have a different MTU,
this means that the overall path MTU can change on a packet-
by-packet basis, negating the usefulness of path MTU discovery.
Variable Latencies
Since each of the redundant paths may have a different latency
involved, having packets take separate paths can cause packets
to always arrive out of order, increasing delivery latency and
buffering requirements.
Packet reordering causes TCP to believe that loss has taken
place when packets with higher sequence numbers arrive before
an earlier one. When three or more packets are received before
a "late" packet, TCP enters a mode called "fast-retransmit" [6]
which consumes extra bandwidth (which could potentially cause
more loss, decreasing throughput) as it attempts to
unnecessarily retransmit the delayed packet(s). Hence,
reordering can be detrimental to network performance.
Debugging
Common debugging utilities such as ping and traceroute are much
less reliable in the presence of multiple paths and may even
present completely wrong results.
And folks I know who build gear which does load-splitting seem to be
scrupulously careful to avoid these sorts of problems.
- Bill
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf