That to me sounds like this is not really a bug, but a performance enhancement; a bug would be something like corrupted/missing/extra data at the application level. Tuning the TCP algorithms beyond the basics is really more of an art.
I would call this a bug fix since someone has found what is probably an unintended behavior in the cubic algorithm. The cubic algorithm itself though would be a feature improving on the original tcp algorithm (nagle, if I remember right)
Imagine a car turning off traction control in a pouring rain every time you stop at the lights because 'Hey,no tire spin in the last 5 seconds!!1'
> that an endpoint that is not moving any traffic cannot use the lack of errors as information in its feedback loop.
I think the bug is that it was counting something when it should have not been, which would have violated both the design and intent even at the time it was written.
But I agree that code is only a bug if it does not do what was originally intended, if the original design was bad, and the code correctly implemented that bad design, there is no bug.
The frame of reference for determining if something is a bug or not is the requirement specification, not design. If the design incorrectly or inadequately addresses the requirement, that is a bug as well. There isn't much point in rejoicing over the code that correctly implements an incorrect design!
if (x = 42) {
If a bit of text was supposed to be blue but came out green, maybe because the person writing the requirements doc got it wrong, it is hardly a bug in the code. The code is doing what the programmer intended, even if that is not what the user wanted. That's why the world has moved on from "bug trackers" to "issue trackers".
> There isn't much point in rejoicing over the code that correctly implements an incorrect design!
And there isn't much point blaming a coder for correctly implementing an incorrect design, especially if the design document is all they have to go on.
Sure. However, that is secondary. The sort of mistakes that you mention can be caught during code review or unit testing, completely independently of what the actual user requirement is. This post, evidently, does not involve such a case.
> The code is doing what the programmer intended, even if that is not what the user wanted.
Your perspective appears to be inside-outward. It may be helpful during a performance appraisal, but does the business no good!
Edit: inside-out --> inside-outward.
If the design has a flaw, whatever the reason: it is a bug.
A big part of development is "discovering the requirements." It is typically the hardest part for real world projects, and when that fails, it is perhaps not a bug in the code, but it still a development error that needs to be fixed.
If a developer got a piece of paper that said "blue" but the real world requirement was "green", and it was not possible for the developer to find out together with any stakeholder, then there is a development process error, that needs to be fixed.
In any event, it needs to be fixed, so pointing to someone else wont really help.