Re: [tcpm] TCP tuning

[Jerry Chu <[e-mail]>]

Hi Joe,

On Wed, Feb 3, 2010 at 9:43 AM, Joe Touch <[e-mail]> wrote:
> 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).

Sure we can do that and will love to hear feedback from ICCRG. But our
preference is IETF simply because we consider a simple, modest
increase of the initial window to be more of an engineering project than
a research problem. The former is more about engineering tradeoff between
cost/risk, benefit and TIMELINESS than a research project to find the best,
elegant, risk free solution with little or no time-to-market concern.

We are aware of all the great research work being conducted at ICCRG
on speeding up slow-start. But none of the proposals seems ready for
IETF anytime soon. I'd be happy to be proven wrong here! (Well to be
more correct a modest increase of initial window may have already been
studied at ICCRG. In that case I'd rephrase it to be the closest to
engineering consideration IMHO.)

Jerry

>
> Joe
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>