Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00
Hello Olivier, On 17/04/2013 12:28, Olivier Bonaventure wrote: Hello, Here are some additional comments on the above draft. Section 4 suggests the utilisation of a hash to perform the load balancing based on the source-address/flow label pair. Hash functions are often used in load balancing applications. I think that it could be useful to point the advantages and the drawbacks of using hash functions for load balancing purposes. The main advantage of hash functions is that they usually exhibit the avalanche effect, i.e. a small change in the input causes a large change in the output of the function. Simulations show that this effect is important to correctly balance real traffic. However, with hash functions, this advantage comes with a drawback. It is difficult to predict the set of inputs that would provide a specific output. That is an advantage from the security point of view, since it prevents an attacker from biasing the load balancing in order to focus a DOS attack on a single server. I believe that's discussed in the flow label spec. Being able to predict which decision will be taken by a load balancer is important for monitoring applications for example. If a network operator wants to verify the round-trip-time between two hosts when there is a load balancer in between, he/she should take into account this load balancing when defining his/her probes. A similar situation happens when a network operator wants to use traceroute to detect block holes on a load-balanced path. True, but there's likely to be little sympathy from the load balancer's operator, for the reason just given. It should be noted that there exist functions that exhibit the avalanche effect without being one-way functions like the classical hash functions. If used in load-balancers, these functions would provide both good load balancing and predictibility which is desired for many monitoring applications. A recent paper shows how such load-balancing can be performed efficiently by using block ciphers instead of hash functions. The solution proposed in this paper could be adapted to utilise the IPv6 flow label : http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks We'll have a look, thanks for the reference. I believe, from the research I had to do personally when working on this draft, that there is scope for an RFC giving a general overview of load balancing. That would certainly have been a precious reference for the current draft. Regards Brian Best regards, Olivier Bonaventure ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00
Brian, Here are some additional comments on the above draft. Section 4 suggests the utilisation of a hash to perform the load balancing based on the source-address/flow label pair. Hash functions are often used in load balancing applications. I think that it could be useful to point the advantages and the drawbacks of using hash functions for load balancing purposes. The main advantage of hash functions is that they usually exhibit the avalanche effect, i.e. a small change in the input causes a large change in the output of the function. Simulations show that this effect is important to correctly balance real traffic. However, with hash functions, this advantage comes with a drawback. It is difficult to predict the set of inputs that would provide a specific output. That is an advantage from the security point of view, since it prevents an attacker from biasing the load balancing in order to focus a DOS attack on a single server. I believe that's discussed in the flow label spec. Well, partially. Since by design all packets with the same pair will always reach the same server, once you have found a victim server, you can send lots of packets to it. I agree that a DDoS from multiple sources could be a bit more difficult since the attacker would need to find the flow label for each source address to reach a given server. Being able to predict which decision will be taken by a load balancer is important for monitoring applications for example. If a network operator wants to verify the round-trip-time between two hosts when there is a load balancer in between, he/she should take into account this load balancing when defining his/her probes. A similar situation happens when a network operator wants to use traceroute to detect block holes on a load-balanced path. True, but there's likely to be little sympathy from the load balancer's operator, for the reason just given. The block cipher algorithm that is described below uses a key. This key can be fixed by the operator. If the key is secret, then only the operator can send packets over specific parts. For attackers, the load-balancing function is similar to a non-invertible hash. This should answer some of your security concerns (at least it's not worst than hash-based load balancing) http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks We'll have a look, thanks for the reference. I believe, from the research I had to do personally when working on this draft, that there is scope for an RFC giving a general overview of load balancing. That would certainly have been a precious reference for the current draft. Yes and the interactions between load balancing and networking protocols is worth being discussed as well. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00
Linda, Thanks for the review. Some comments in line. I have added our co-author in cc because I'm not sure whether he's on the list. On 05/04/2013 21:53, Linda Dunbar wrote: Sheng, Brian, el at: I reviewed draft-ietf-intarea-flow-label-balancing-00 Here are my comments: - The draft is to suggest using IPv6 header's flow label field to identify different flows from IPv6 hosts. The draft tries to emphasize that the flow label can help devices along the way between Source destination to achieve better flow separation or finer tuned traffic balancing if there are multiple paths. However, the Section 3 devotes so much to various LB schemes. But many are irrelevant. There are many different types of Load Balance, True, but as far as I can tell this topic is quite badly known in the IETF and it's useful to give an overview for people. the DNS based load balancing, which is often called global LB, has nothing to do with LB in front of a cluster of servers. It can be used to select members of a single cluster, in fact I remember that technique being used in the very early days of cluster computing. I agree that today it's normally used for wide area LB, so we can clarify that in the text. Some description about LB in Section 3 is not quite to the point. For example, the second bullet you stated: Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm. The LB in front of a cluster of servers is orthogonal to DNS based global LB. Yes, maybe the text needs to be broken up into separate paragraphs. Your draft didn't even mention Direct Server Return (DSR) LB scheme which is used heavily in DC to balance load among a cluster of servers. In this scheme, all the servers in a cluster share a common IP address which is same as the LB, or use floating IP address for hosts. We didn't think this was relevant because it is part of the magic *behind* the load balancing point (i.e. the flow label has already been analysed before sending the packet on to the individual server). We can certainly explain that point. Similarly we didn't think that the actual LB algorithm (round robin etc.) was relevant. The figure in Page 7 is has some errors too. The DNS based Load Balancing is usually in the Access network. See above - we are not talking about DNS for wide-area LB, but for flipping the address within one site. (I really think this figure is not necessary because it doesn't help the draft at all). See above - we think it helps people who are new to the topic. The LB for Server Cluster is more likely located in a Data Center. More likely than what? We don't say anything about where the server cluster lives. Regards Brian Therefore, I suggest that you replace Section 3 with following: 3. Summary of Load Balancing Techniques: There are many different types of Load Balancing in networks. There is DNS based global LB, typically placed closer to clients, there are also LB for a cluster of servers who share same IP address as the LB, there are other LB. This draft is to describe how flow label can further optimize load balancer in front of a cluster of servers. Highlight of Load Balancing Algorithms: Typical industry standard load balancing algorithms available today include: Round Robin Least Connections Fastest Response Time Weighted Round Robin Weighted Least Connections Custom values assigned to individual servers in a pool based on SNMP or other communication mechanism 4. An improved Load Balancing Algorithms using Flow Label (you can describe how Flow Label improve the LB algorithms currently being deployed). Linda -Original Message- From: Sheng Jiang Sent: Monday, April 01, 2013 9:04 PM To: Linda Dunbar Subject: RE: Reviewing of flow label balancing http://tools.ietf.org/html/draft-ietf-intarea-flow-label-balancing-00 Many thank, Sheng -Original Message- From: Linda Dunbar Sent: Monday, April 01, 2013 10:14 PM To: Sheng Jiang Subject: RE: Reviewing of flow label balancing Sheng, Sorry for slipping through my mind. Can you send me the link? Linda -Original Message- From: Sheng Jiang Sent: Monday, April 01, 2013 2:02 AM To: Linda Dunbar Cc: Brian E Carpenter; Suresh Krishnan Subject: Reviewing of flow label balancing Hi, Linda, You volunteered to review our flow label balancing document during the IntArea meeting in Orlando. Could you please confirm when we can get your feedback? Many thanks and best regards, Sheng ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00
Sheng, Brian, el at: I reviewed draft-ietf-intarea-flow-label-balancing-00 Here are my comments: - The draft is to suggest using IPv6 header's flow label field to identify different flows from IPv6 hosts. The draft tries to emphasize that the flow label can help devices along the way between Source destination to achieve better flow separation or finer tuned traffic balancing if there are multiple paths. However, the Section 3 devotes so much to various LB schemes. But many are irrelevant. There are many different types of Load Balance, the DNS based load balancing, which is often called global LB, has nothing to do with LB in front of a cluster of servers. Some description about LB in Section 3 is not quite to the point. For example, the second bullet you stated: Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm. The LB in front of a cluster of servers is orthogonal to DNS based global LB. Your draft didn't even mention Direct Server Return (DSR) LB scheme which is used heavily in DC to balance load among a cluster of servers. In this scheme, all the servers in a cluster share a common IP address which is same as the LB, or use floating IP address for hosts. The figure in Page 7 is has some errors too. The DNS based Load Balancing is usually in the Access network. (I really think this figure is not necessary because it doesn't help the draft at all). The LB for Server Cluster is more likely located in a Data Center. Therefore, I suggest that you replace Section 3 with following: 3. Summary of Load Balancing Techniques: There are many different types of Load Balancing in networks. There is DNS based global LB, typically placed closer to clients, there are also LB for a cluster of servers who share same IP address as the LB, there are other LB. This draft is to describe how flow label can further optimize load balancer in front of a cluster of servers. Highlight of Load Balancing Algorithms: Typical industry standard load balancing algorithms available today include: Round Robin Least Connections Fastest Response Time Weighted Round Robin Weighted Least Connections Custom values assigned to individual servers in a pool based on SNMP or other communication mechanism 4. An improved Load Balancing Algorithms using Flow Label (you can describe how Flow Label improve the LB algorithms currently being deployed). Linda -Original Message- From: Sheng Jiang Sent: Monday, April 01, 2013 9:04 PM To: Linda Dunbar Subject: RE: Reviewing of flow label balancing http://tools.ietf.org/html/draft-ietf-intarea-flow-label-balancing-00 Many thank, Sheng -Original Message- From: Linda Dunbar Sent: Monday, April 01, 2013 10:14 PM To: Sheng Jiang Subject: RE: Reviewing of flow label balancing Sheng, Sorry for slipping through my mind. Can you send me the link? Linda -Original Message- From: Sheng Jiang Sent: Monday, April 01, 2013 2:02 AM To: Linda Dunbar Cc: Brian E Carpenter; Suresh Krishnan Subject: Reviewing of flow label balancing Hi, Linda, You volunteered to review our flow label balancing document during the IntArea meeting in Orlando. Could you please confirm when we can get your feedback? Many thanks and best regards, Sheng ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
