James Carlson wrote: > When do I move VNICs around and what do I need and expect? I think > this document should work through some actual usage scenarios and then > come up with usable interfaces based on that, because the current > interfaces seem to be self-referential: they do what they do because > that's what they do. The "force" flag seems particularly problematic, > as it indicates that things the administrator should be able to do > aren't doable.
<snip> We need the ability to assign a factory MAC address or fail the operation is none is available. I don't see a problem with that. There's the "auto" (also the default) option for administrators who want to have a factory address if one is available, but don't mind to have a random address assigned if no factory address is available. I'm fine for not having a "force" option during the move operation. This means that if a VNIC was created with a "factory" option, and the destination NIC doesn't have a factory MAC address available, then the move will fail. It also means that if a user explicitly specified a factory MAC address slot, the move will fail. >>> I've seen similar schemes for access servers (most have proprietary >>> RADIUS extensions for setting bandwidth limits), and the usual way >>> this works is that once the link is saturated, the configured limits >>> become shares. Thus, the clients are all hurt in proportion to the >>> amount of bandwidth they're given. >> The limits are really used to clamp down on bandwidth utilization by a >> MAC, but they do not imply any guaranteed bandwidth. As a future >> deliverable we're also planning to provide bandwidth guarantees which is >> what you seem to be referring to here. > > Actually, no, that's not quite what I'm referring to. > > A bandwidth limit is an upper bound. If the user tries to send more > than that, then he'll experience delay and loss. There's no guarantee > that he'll be able to send that much, but he won't be able to send > more. > > A bandwidth guarantee is a lower bound. It's a reservation. The user > must always be able to get at least a given amount. This project > doesn't supply guarantees. Right. > Quite apart from those definitions, though, is the issue of fairness. > In this case, I *am* talking about limits, but I'm also talking about > what happens when the limit is unachievable. In the implementations > I've seen (Cisco and Ascend are pretty good references for this), the > limit becomes a share because this sort of behavior preserves > fairness. > > Suppose we have twenty users with 10Mbps limits, and one user with a > 50Mbps limit. They're all on a 100Mbps pipe. If ten of those 10Mbps > users can together lock out all of the others from using any of the > pipe bandwidth at all, then that's an "unfair" result. > > A very simple, but "fair," result would be that, in the limit with > everyone sending flat-out, the 50Mbps-limited user would get 20% of > the bandwidth, or 20Mbps. The 10Mbps users would get the remaining > 80%, or 4Mbps. Thus, each user would end up with 40% (which is > 100/250 and 20/50 and 4/10) of his maximum. I think this is an RFE we should consider. I'll let the rest of the team chime in if they disagree or have more to add. >>> Why is the resource allocation itself an important thing to optimize >>> versus the interface stability and scalability? >> I don't agree with the "core function" vs "periphery" argument. The >> resource control is becoming an integral part of the MAC layer, and >> there shouldn't be a need to do "extra steps" to enable that functionality. > > Opening the device is clearly core functionality -- you can't do much > if you can't open it. It sounds like you agree that if those > arguments weren't present, then some "default" set of resources would > need to be allocated. Thus, I argue that the functionality isn't core > to the goal of getting access to the mac layer. If we have the hint at open time, then we can do it right there instead of doing a first default allocation followed by a new allocation when the hint is specified. >> Yes, this will be of course fully documented. If we find an efficient >> way to do banwidth control across multiple rings in the future, I don't >> see why we wouldn't be able to made use of that functionality. > > Not just "fully documented," but the design constraint around the > units of control (being individual NIC instances) needs to be clearly > described. Maybe I'm atypical but, as a user, this wouldn't be > obvious to me. Sure, we're planning to document this already. Nicolas. -- Nicolas Droux - Solaris Networking - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux
