IAM ====== Name: ILB: Integrated L3/L4 Load balancer (2008/575) Submitter: Sangeeta Misra Owner: Sebastien Roy Interest: Status: inception scheduled 12/03/2008 Exposure: open Comment: Intern: Mark Martin SUMMARY ======= ILB project will deliver the basic features needed for Solaris to be used as a L3/L4 load balancing solution on SPARC and X86 platforms. This solution can also be used by third party load balancing solutions. ISSUES ====== gcs justify need for new uid =====> general issue; need to include in opinion. Refer to Nico's case. jc what is the relationship / dependencies / requirements with the VRRP project for this one. djr-00 Why does load balancing need to be a part of a core part of IP? This is a non-essential and non-compulsory function and should only need to be present on systems where it is configured to run. Having this inside of IP adds bloat to IP and the base kernel size. Architecturally, there should be no reason why it needs to be a part of IP. If it does then it suggests that there are deeper faults in the project's use of interfaces and architecture. Further, if this module needs access to "internal" data structures and functions then documenting those as an external module helps us to understand what functionality we need to export from IP to support developers that wish to develop kernel level modules that provide value added functionality in appliances. djr-01 Is there an architectural reason why you cannot support correct load balancing of IP fragments or is it just an implementation issue? If it is architecture, doesn't this suggest the project needs to rethink its solution? If it is implementation, why should the project be let off the hook for partial interoperability with IP? =====> Not a must need requirement by customer / not an architecturalfeature / can be added later. djr-02 Are standard sockets being used or will a ilb-specific socket be used and thus a new sockmod delivered? If it is the former, details on what type of sockets (AF_INET,SOCK_RAW), etc, would be useful. If it is the latter, details on the new sockmod are required. =====> Will be using standard sockets. djr-03 Why is this project implementing yet another private hook inside of IP's forwarding path rather than implementing and using a public hook using PSARC/2005/334 and PSARC/2008/219? Whilst the exisiting forwarding hook may not export the correct data for load balancing, if this project were to publish a new packet event, even if it were uncommited, it would encourage external projects/developers to use it and hopefully contribute to building community involvement. =====> djr-04 When a process writes out the RTT to stdout, what should the RTT be measured in? Further, is it a decimal number or an Integer? Further, is a range of 1-254 sufficiently large enough for the user process to provide adequate coverage of the acceptable RTT values? One suggestion is for the RTT emitted by a user task to be in nano-seconds (ping already reports these) and to use -1 and 0 as "special values" and to support reading in an RTT of [1,MAXINT] as "normal." =====> will look into nano seconds. djr-05 To elaborate further on 10.3, the use of ILB NAT with IPFilter will not interoperate well with stateful filtering. Current stateful filtering on a system that routes packets only requires one state entry per "flow" (i.e. TCP connection) even though IPFilter's NAT may be used on either side because IPFilter is able to match up packet details in its NAT table. The use of an external NAT, such as ILB's, will require 2 state table entries per connection because IPFilter is unable to map the changed headers back. =====> using own map for performance related reasons; need more specificity djr-06 In 9, I'm guessing a typo at the end of the paragraph, unless PSARC is 1800+ years old (PSARC/200/517) djr-07 An interface table is required. THE NEXT STEP ============= Seb / Mark Martin to send summary to case log: Seb's summary In addition to the responses that Sangeeta already provided in the issues file, the relevant parts of today's Inception review were: * Regarding djr-00 and the general interaction with filtering hooks: There isn't very much ILB specific code in the ip kernel module itself. Only the hooks are part of the IP datapath code, and those don't comprise very much code. Erik Nordmark gave an overview of the reasons why filtering hooks aren't a good fit for load balancing. Specifically, there are requirements on the location of the hooks which the filtering hooks don't meet, as well as issues regarding the ordering of the hook callbacks. There are also semantic requirements of the load balancing hooks (the ability to change the next hop on output for example) that the filtering hooks don't provide in an efficient way. There were concerns raised that the lack of a general-purpose hook mechanism (despite the claims that there is already such a mechanism, it doesn't appear to be the case) is leading to exploding complexity in the IP implementation. Erik noted that the existence of a general-purpose hook mechanism would not necessarily address the complexity problem due to the sensitive nature of the interactions between the different hook consumers. Given this information, the committee asks the project team to clearly document the interactions between load balancing and other hooks such as filtering, observability, and Dtrace probes. * Regarding Jim Carlson's whiteboard level 0: requirements on VRRP Sangeeta Misra noted that there are two failover cases that will use VRRP, neither of which would require any feature beyond what is currently defined in the VRRP RFC. There are more details in appendix C of the design document. This project does not require "grouping" (a feature that was initially included in the VRRP case), nor the scripting interface that is being defined by VRRP. Sangeeta took an action-item to send mail to the VRRP case log to state the requirements that this case poses on VRRP. * Regarding Glenn Skinner's issue of "one more special-purpose uid": Do we really need another special-purpose user-id? The project team will investigate whether this is really needed, including the possibility of using "root" with dropped privileges. There should be advice in the opinion for this case to the appropriate management team on defining architecture suitable to allow projects to use user-id's other than "root". -Seb