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

[Lachlan Andrew <[e-mail]>]

On 15 November 2010 12:41, Mark Allman <[e-mail]> wrote:
>
>> On 13 November 2010 04:01, Stefan Hirschmann <[e-mail]> wrote:
>> >
>> > To be honest. I don't like the idea that an application behaves
>> > different depending on the used TCP variant. For me, TCP is kernel
>> > stuff and an application should use it without thinking.
>>
>> Applications very often check the version of OS or CPU they are
>> running on, and behave differently accordingly.  Doing this for TCP
>> wouldn't be setting a precedent.
>
> I am not sure that analogy holds.  An app that looks at the OS or the
> CPU can get a complete story of what's up.  Checking on TCP seems a
> little more tenuous because it isn't really TCP that we're concerned
> about, but rather the state of the path relative to the TCP config.
> And, its hard to understand the state of the path.

I agree the application shouldn't follow the TCP state, but that is
different from adapting to which variant is used.  I thought the issue
was "If we fix problem  X  of TCP (very slow to start), should
applications be able to test whether that fix has been made, and
disable their old work-arounds (opening multiple connections) if it
has?"

Of course, it isn't that simple, because the work-around of opening
many connections may give selfish users additional benefits even if
underlying issues are fixed and so the incentives are wrong.  However,
I don't see a problem in principle with an app adapting to the flavour
of TCP, any more than an app getting a choice of DCCP congestion
control algorithm, or using DCCP if it is available and UDP otherwise.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph [phone]