Re: [tcpm] TCP tuning

[Joe Touch <touch at ISI.EDU>]

Hi, Michael,

Michael Welzl wrote:
>> 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?

That's been tried in various ways in various IETF efforts. Some try to
find the properties of the immediate link, which are expected for some
link types to dominate the path. Some try to detect path properties.
Some reuse information from past connections.

None of that is all that bad.

...
> 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!  :-)  )

I think revising congestion control to be smarter is already a IRTF
effort (aren't you active in that already?):

http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG

IMO, I would encourage Google to take their work there and get feedback
there first. TCPM is a place where mature, vetted ideas should be
considered, preferably (IMO).

Joe

Attachment: signature.asc
Description: OpenPGP digital signature