Kacheong Poon wrote: > Darren Reed wrote: > ... >> But which project is going to pickup the work of fixing the >> root causes that you're alluding to here? > > > Over the years, we did a number of RFEs for this kind of > things. I don't believe that this needs a project... As > a simple example related to the current discussion, some > customers wanted to change the timeout values on a per > connection basis many years ago. So we did a simple RFE > for that. > > I don't see the need to have a project to implement > something we "think" will be tuned by some "unknown" > customers. As I mentioned before, those tunables are not > supposed to be changed normally. They are there to handle > exceptional cases without the need to ship a new binary to > solve a customer's issue. If the need to change a tunable > becomes normal, we can do a RFE to solve the case. > > What project are you thinking we need to do? And what > is the problem you think we need to solve?
So the problem that is in the back of my mind, with respect to all of these tunables, is where applications run on a system that has completely different network characteristics for its various application connections. Internal ones may be all 1G or 10G but external ones might be over much slower HDLC connections. In order to perform well for slow HDLC stuff, it can be desirable to tune TCP in a specific way but that is counter to what is good for ethernet. At the time that work was being done, requests to have the timeouts made per-socket were pretty much ignored by Sun (I'm talking in the 3rd person about Sun because this was when I was working on development projects that were being deployed on Sun gear and we had to try and make the stuff "work".) Now why would you want the tuneables for TCP? Maybe you are working with applications for which you don't have source, applications that don't allow you to tweak things inside TCP. >> So to summarise... >> - the timeout tunables shouldn't need to exist and therefore >> don't need further exposure - I'll accept that if there is >> a commitment and plan to actually fix the root causes. If >> the root causes aren't going to be fixed, then that undermines >> not providing them... > > > What do you mean by "root causes?" What exactly is the > problem you referred to above? The need to change some > timeout values? There is no root cause as there is really > not a problem. A customer wants to do something special > in their own private network. So they don't want the > default timeout values. There is no fancy reason. > > >> - then there are non-timeout tunables, such as the "root only" >> ports, tcp default listen queue length and anonymous port >> (high/low) as being ones I can name without looking at source >> code. > > > Why does someone want to change the above tunables on a > per interface/address basis? Is this a normal need? When all your connections are the same speed, it's not a big problem to tune everything "in one direction." >> Can it then meaingfully print out IP and TCP properties together? > > > What is the problem you see here? The output as presented lists properties as they would be applied with respect to interfaces. That doesn't always make sense, to me. Darren
