Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

[Jerry Chu <[e-mail]>]

Hi Joe,

On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch <[e-mail]> wrote:
> Hi, Jerry (et al.),
>
> The logic here is astounding.
>
> We can't use a reactive system because it would make the wrong decision, and
> potentially treat all endpoints the wrong way.

We can't use a reactive system like the one you suggested because it just
doesn't work (except in a few limited cases). We are debating on an engineering
issue here and this is IETF so we'll need running code and real deployment
experience. If you can demonstrate your idea in a large server farm environment
without requiring a large amount memory and complexity and actually showing
reasonable performance latency I'll jump on it tomorrow!

I think being conservative to the extreme is like saying "TCP is not
to be touched".
This will likely force application developers frustrated with TCP
performance into
ways that circumvent TCP and cause a lot of more damage dwarfing the one
you've been worried about.

Jerry

>
> So let's make a static decision that is, essentially, the same as the
> automatic one with particular parameters (A=0, M=1, timescale=infinite,
> aggregation=all). Alternately, for Mark's proposal, that would be (A=+k,
> M=1, timescale=every few years, aggregation=all).
>
> I conclude that:
>
>        - if there is no objective metric for the safety of this
>        change, it MUST NOT be deployed
>
>        - if there is an objective metric for its safety, it's surely
>        more safe to incorporate that as a test
>
> Even if all the 'auto' system does is backoff to IW=3 if IW=10 causes
> persistent problems, that's MUCH SAFER than anything else.
>
> If, as Mark concludes, an auto system isn't ready for prime time because we
> don't know the impact, then surely we don't have enough info for a static
> configuration of that auto system either.
>
> Joe
>
>