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

From: Lachlan Andrew <[email-masked]>
Date: Mon, 15 Nov 2010 15:57:43 -0800

On 15 November 2010 12:41, Mark Allman <[email-masked]> wrote:
>
>> On 13 November 2010 04:01, Stefan Hirschmann <[email-masked]> 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 +61 3 9214 4837

---

From: Mark Allman <[email-masked]>
Date: Mon, 15 Nov 2010 20:56:31 -0500

> 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?"

OK.  So, the client wants to issue small requests to some server and
expects content in return (a la HTTP).  How many connections should it
open?  The server controls the initial cwnd that matters and the client
controls the number of parallel connections.

allman

---

From: Lachlan Andrew <[email-masked]>
Date: Mon, 15 Nov 2010 18:17:18 -0800

> controls the number of parallel connections.

Good point.  That is a compelling argument.  I was only refuting the
argument that for an app to talk to its own kernel about its TCP
variant is some sort of layering violation.  Perhaps I misunderstood
the original poster.

Cheers,
Lachlan

---

From: <[email-masked]>
Date: Tue, 16 Nov 2010 08:23:28 +0000

On 16 Nov 2010, at 01:56, Mark Allman wrote:

open?

RFC 2068 section 8.1:
   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD maintain AT MOST 2 connections with any
   server or proxy.

The server controls the initial cwnd that matters and the client
controls the number of parallel connections.

allman

Lloyd Wood
[email-masked]<mailto:[email-masked]>
http://sat-net.com/L.Wood