Re: [tcpm] TCP tuning

[Michael Welzl <[e-mail]>]

> Michael Welzl wrote:
>>> Agreed. The point is to what extent TCP is modified for fractional
>>> benefits for specific communities. TCP is "optimized" to always  
>>> work,
>>> but not to work especially well in any particular environment.
>>
>> Yeah... stupid, isn't it?
>
> I'll trade "always" or even "usually" to "works very well in some
> places, but not at all in others".
>
> Making TCP smarter is fine; doing so at the expense of robustness is  
> not.

Sorry for being so unspecific - I was just thinking out loud...
my point was: isn't that actually a stupid situation?

Why do we have to worry about TCP over wireless, when so
many users know perfectly well that their access link is WiFi?
Why do we have to worry so much about raising the window
when it's perfectly clear in some cases (at least from the
combined knowledge of the stack + its users) that a certain
connection is only going to face high bandwidth conditions?

In other words, why not harness this knowledge somehow,
and develop a customized transport protocol, or ways of
customizing what we now have?

This is what I was hinting at. Just thoughts... which would be
more appropriate in an IRTF than in an IETF list, in fact - sorry.

To get back to the point, I'm not seriously suggesting to reduce
TCP's robustness and I'm in your camp about the larger
window thing. My personal opinion here is that, however,
the current slow start is indeed questionable, and questioning
it should be done, in large scale thorough experiments. I'm
interested in this and started some such work with a master
student; I might continue if I get another one (or if I can nicely
make that fit as a part of a larger Ph.D. thesis - ideas for
how to do that are welcome!  :-)  ).

Cheers,
Michael