I have now updated the load sharing doc in response to the discussion on the list so far, and would like to request a WG last call.
Responses to Pekka's email below (others that commented said similar things). Pekka Savola wrote: > I have major, fundamental objection to the premises on which this > draft is based on. However, I think we should be able to find > consensus on the way forward. > > Fundamental objection > --------------------- > > The document assumes that it is always desirable to do load-sharing > with the equivalent routers. I don't agree with this assumption. > > If the router's capacity is sufficient so that it can forward all the > traffic sent by its nodes, there is actually very little need for load > sharing. On the contrary -- sharing load between routers produces > difficult-to-debug scenarios when some destinations (which are > distributed to some routers) fail in mysterious ways while others work just fine. > > Due to that, I, as an operator, would not wish to enable load-sharing > on hosts except when I specifically require that kind of functionality. > > So, I'd propose that this document does not describe that the hosts > MUST share the load, but rather describes how the hosts MUST behave if > they wish to share the load To summarize the other discussion on the list on this topic: A number of other folks (Changming Liu, Tim Chown, and Suresh Satapati) also argued on the list against the MUST, while others (such as Bob Hinden) have argued for it on and off the list. In draft-02, I have changed the MUST to a SHOULD as a result. > -- and if turned on by default, require that there MUST be a way to > toggle load balancing off. A difficult issue to settle might be > whether to recommend (and if so, how strongly) to enable load-sharing > by default. I am not particularly eager to add any MUSTs at this point, as there seems to be lack of consensus on any MUST. For example, if you have an embedded device designed for a very specific application, "MUST be a way to toggle" seems too much to argue for. I agree it would be difficult enough to come to consensus on any text discussing defaults and toggling configuration, and as a result, draft-02 is silent on this issue.. The relevant paragraph in draft-02 is now: | When a host chooses from multiple equivalent routers, it SHOULD | support choosing using some method which distributes load for | different destinations among the equivalent routers rather than always | choosing the same router (e.g., the first in the list). Furthermore, | a host that does attempt to distribute load among routers SHOULD use a | hash-based scheme, such as those described in [MULTIPATH], which takes | the destination IP address into account. > substantial > ----------- > > [ND] does not require any particular behavior in this respect. It > specifies that an implementation may always choose the same router > (e.g., the first in the list) or may cycle through the routers in a > round-robin manner. Both of these suggestions are problematic. > > Clearly, always choosing the same router does not provide load > sharing. Some problems with naive tie-breaking techniques such as > round-robin and random are discussed in [MULTIPATH]. While the > destination cache provides some stability since the determination is > not per-packet, cache evictions or timeouts can still result in > unstable or unpredictable paths over time, lowering the performance > and making it harder to diagnose problems. Round- robin selection may > also result in synchronization issues among hosts, where in the worst > case the load is concentrated on one router at a time. > > ==> I don't think this document clearly described both of the above > suggestion (1st paragraph): but rather how round-robin and random have > issues. That is, it does not cleatly describe why choosing the same > router is undesirable. Clarfied by changing second sentence to | Some problems with load sharing using naive tie-breaking techniques | such as round-robin and random are discussed in [MULTIPATH]. > As mentioned in [MULTIPATH], when next-hop selection is predictable, > an application can synthesize traffic that will all hash the same, > making it possible to launch a denial-of-service attack against the > load sharing algorithm, and overload a particular router. A special > case of this is when the same > (single) next-hop is always selected, such as in the algorithm allowed > by [ND]. Introducing hashing can make such an attack more difficult; > the more unpredictable the hash is, the harder it becomes to conduct a > denial-of-service attack against any single router. > > ==> these threats appear to have no clear threat model. What's the > point of such an attack, as you're already on-link, and can already > DoS the routers there using a number of means? Not quite true. A remote attacker can conduct such an attack too, as long as he has the ability to spoof/use a bunch of different source addresses. Added the sentence: + This can even be done by a remote application that can cause a host to + respond to a given destination address. However, you are correct in that there's not really much of a threat there, since there are other ways of doing the same thing. But it seems better than claiming there's no security issues whatsoever. > Introducing hashing doesn't help much here > -- > you're making an assumption that the attacker is a "friendly" node. A > maliscious node will just a) send the packets through raw sockets, > DoSing the routers directly, or b) overload both of the routers :). > It seems the security considerations needs a rewrite... With the above clarification, I think the text is sufficient. If you feel otherwise, please submit proposed text. > editorial > --------- > > ==> all the empty lines in the document appear to have been duplicated > for some reason. I don't see this. Perhaps a CR/LF issue? > Abstract > > The original IPv6 conceptual sending algorithm does not require > load-sharing among equivalent IPv6 routers, and suggests schemes > > ==> s/IPv6/IPv6 Neighbor Discovery/ Disagree. Although it's in the ND spec, the relevant part of the algorithm here is not specific to links which actually run full ND. Hence I find it less confusing the way it is. It's a trivial point in any case. > Subsequent traffic to the same > destination address continues to use the same router unless there is > some reason to change to a different router (e.g., a redirect message > is received, or a router is found to be unreachable). > > ==> s/a router/the router/ Done. > 9. Full Copyright Statement > > ==> IPR boilerplate prior to this document would not hurt. Done. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
