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

[Jerry Chu <[e-mail]>]

Hi Joe,

On Fri, Nov 19, 2010 at 10:48 AM, Joe Touch <[e-mail]> wrote:
> Hi, Jerry,
>
> The reasons you give for this all being too complex to deploy are great
> reasons we cannot afford to take a risk on IW=10.
>
> If you can't monitor it and tell us whether it works, you're seriously

I'm confused - isn't it what we've been trying to do for the past three
IETF meetings, backed with lots of data from both large scale real
experiments and testbed emulation, to tell the world IW10 works?
Or we've just been too subtle? :)

Jerry

> asking us to just do it anyway, blindly?
>
> Joe
>
> On 11/19/2010 10:45 AM, Jerry Chu wrote:
>>
>> On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch<[e-mail]>  wrote:
>>>
>>>
>>> On 11/19/2010 9:58 AM, Jerry Chu wrote:
>>>>
>>>> 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!
>>>
>>> It's simpler than you're thinking, and doesn't require code in the data
>>> path:
>>
>> Well, it's not as simple as you think because the devil is in the details,
>> and we had to deal with all the details in order to perform real
>> experiments
>> before giving up. (See my slides mentioned in previous email.)
>>
>>>
>>> 1) pick an IW s
>>>
>>> 2) keep stats on whether the IW works
>>>        this can be within every single connection, or done out of
>>>        band using tracers as separate machines
>>>
>>> 3) lower the IW if it tends to result in retransmits
>>> (possibly even increase it over longer timescales if it doesn't result in
>>> retransmits)
>>>
>>> This can happen on the timescale of days. Weeks even. I'm not talking
>>> about
>>> something that needs to happen in realtime.
>>
>> We've tried both the realtime and the offline schemes (again see my
>> slides).
>> I've mentioned the problem with the realtime one in my previous email. For
>> the offline scheme, do you realize how many subnets are their even in just
>> a
>> region, how much memory it requires, and how much work it takes to try to
>> import the data into the kernel and make it work efficiently?
>>
>> Again please show me your "simple" implementation and success experience.
>>
>> Jerry
>>
>>>
>>> The point is to automate the feedback mechanism that Mark and I discussed
>>> as
>>> necessary.
>>>
>>> Joe
>>>
>