Re: [dnsop] [dean@xxxxxxx: Mismanagement of the DNSOP list]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]