On 2/7/13 12:04 PM, George Neville-Neil wrote:
On Feb 6, 2013, at 12:28 , Alfred Perlstein <bri...@mu.org> wrote:
On 2/6/13 4:46 AM, John Baldwin wrote:
On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote:
John:
A burst at line rate will *often* cause drops. This is because
router queues are at a finite size. Also such a burst (especially
on a long delay bandwidth network) cause your RTT to increase even
if there is no drop which is going to hurt you as well.
A SHOULD in an RFC says you really really really really need to do it
unless there is some thing that makes you willing to override it. It is
slight wiggle room.
In this I agree with Andre, we should not be *not* doing it. Otherwise
folks will be turning this on and it is plain wrong. It may be fine
for your network but I would not want to see it in FreeBSD.
In my testing here at home I have put back into our stack max-burst. This
uses Mark Allman's version (not Kacheong Poon's) where you clamp the cwnd at
no more than 4 packets larger than your flight. All of my testing
high-bw-delay or lan has shown this to improve TCP performance. This
is because it helps you avoid bursting out so many packets that you overflow
a queue.
In your long-delay bw link if you do burst out too many (and you never
know how many that is since you can not predict how full all those
MPLS queues are or how big they are) you will really hurt yourself even worse.
Note that generally in Cisco routers the default queue size is somewhere between
100-300 packets depending on the router.
Due to the way our application works this never happens, but I am fine with
just keeping this patch private. If there are other shops that need this they
can always dig the patch up from the archives.
This is yet another time when I'm sad about how things happen in FreeBSD.
A developer come forward with a non-default option that's very useful for some
specific workloads, specifically one that contributes much time and $$$ to the
project and the community rejects the patches even though it's been successful
in other OSes.
It makes zero sense.
John, can you repost the patch? Maybe there is a way to refactor this somehow
so it's like accept filters where we can plug in a hook for TCP?
I am very disappointed, but not surprised.
I take away the complete opposite feeling. This is how we work through these
issues.
It's clear from the discussion that this need not be a default in the system,
and is a special case. We had a reasoned discussion of what would be best to do
and at least two experts in TCP weighed in on the effect this change might have.
Not everything proposed by a developer need go into the tree, in particular
since these
discussions are archived we can always revisit this later.
This is exactly how collaborative development should look, whether or not the
patch
is integrated now, next week, next year, or ever.
I agree that discussion is great, we have all learned quite a bit from
it, about TCP and the dangers of adjusting buffering without
considerable thought. I would not be involved in FreeBSD had this type
of discussion and information not be discussed on the lists so readily.
However, the end result must be far different than what has occurred so far.
If the code was deemed unacceptable for general inclusion, then we must
find a way to provide a light framework to accomplish the needs of the
community member.
Take for instance someone who is starting a company that needs this
facility. Which OS will they choose? One who has integrated a useful
feature? Or one who has rejected it and left that code in the mailing
list archives?
As much as expert opinion is valuable, it must include understanding and
need of handling special cases and the ability to facilitate those
special cases for our users and developers.
-Alfred
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
