[e2e] TCP Performance with Traffic Policing

[Detlef Bosau]

On 08/18/2011 09:06 PM, Hagen Paul Pfeifer wrote:
> * Detlef Bosau | 2011-08-18 20:44:53 [+0200]:
>
>>> Detlef, I don't understand your critics about Quick ACK. Quick ACK as used in
>> I absolutely don't have any problem with Quick ACK.
>>
>> My problem is basically, that there are at least as many TCP as OS.
> I can't speak for other operating systems (with a exception of FreeBSD where I
> follow the development loosely), but for Linux I can provide guarantee that all TCP
> related development is judged. A standard-compliant implementation is ultimate
> ambition (not to harm any other TCP instance).


It is a well proven attitude in science, to do research one step after 
another.

Obviously, in Internetworking we have a certain problem with this one. 
Why couldn't we discuss those things in a number of papers and/or RFC 
proposals instead of playing around with these things, with absolutely 
no consideration of the rest of the world?

If Quick ACKs are a good idea, there is no doubt that they will be 
accepted. However, I have a problem with working beside/without/against 
the community.

My attitude is pursuing the discussion in the community (although I 
cannot do this to that degree I want to do for some reasons) instead of 
avoiding it.

In some sense, Linux is the OS of the GNU generation: Gnu is Not Unix.

And many of us use still BSD Unix as _the_ reference.

When I look at Linux, we have Westwood and Reno Options and others as 
well. So, every user make mix up his own "salad of TCP flavours" wihout 
ging a simple thought to whether this make sense.

This is an attitude of competitive playing - and I strongly expect our 
attitude to become more professional in the future.

> Variety IS good as long as the default is the best possible default. There are

Variety is good. However: Variety is somewhat different to chaos. And 
there is absolutely no place for variety in productive setups. And some 
users attempt to place Linux as a commercial product exactly there. In 
consequence, the discussion of Vegas or Westwood is a discussion between 
M$ Hackers and know-it-alls who boast with "registry hacks". Excuse me, 
but this is not a professional attitude. This is laymanship. To avoid 
the word botch.

Proper engineering is something completely different.


> several timer knobs, CC algorithms, queues, memory knobs and so on - you are

Fine. Refer to the Hengarter et al. paper on TCP Vegas, how "several 
knobs" are discussed properly.



> absolutely right. They are provided to tune the stack to meet your
> requirements, to fit into divergent environments.  If you know your
> environment and you want to tune something, fine, Linux provides a way.

When I compare Germany and what I here, e.g., from Cuba, I'm convinced 
that it is a good idea, that not each and everyone may tune his car as 
he wants to, if he only thinks this to be appropriate.

> Other OS do the same!

Which is the same bad.

>   Since several months FreeBSD also provides a way to
> select the CC algorithm on the fly.

Oh yeah.

Do you remember the congavoid paper?

One of VJ's goals was achieving and maintaining stability. How can this 
be ensured by a free choice of cc-algorithms without any solid rationale?

> We are embedded in a complicated (network) world, there is more then just one
> answer.
>
>
Even more, it is necessary to obey the principle of robustness, to be 
conservative and to be very considerate in what we're doing.

Scientific progress is achieved by carefully doing one step after 
another. Not by chaotic stumble.

Detlef

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------