[e2e] TCP goodput as a function of connection count

[Vimal]

Hi Zartash,

>From my understanding:

(a) the gain from increased number of connections to a single server
is at the expense of all users sharing the bottleneck link.

(b) yes, by opening multiple connections, what the client is achieving is:
1. Increased starting window size,
2. An increased rate of increase in the AIMD phase.

In each case, the rate of increase is proportional to the number of
connections the client opens with the server. So what the OP means is
that if we modify the TCP algorithm to scale the initial window size
and the rate of increase, the multiple connection case reduces to a
single flow. (barring other possible overheads associated with
multiple TCP flows.)

Regards,
On 4 April 2010 20:48, Zartash Afzal Uzmi <zartash at lums.edu.pk> wrote:
> Thanks Lachlan,
>
> That is a fairly good explanation.
>
> (a) When you say that in the first case, something is gained by parallelism,
> you do mean a gain for the community as a whole and not just for one user at
> the expense of others, right?
>
> (b) Altering Reno's behavior (to overcome slow decrease and rapid decrease)
> is the same as changing the congestion control algorithm. You appeared to be
> saying that: in the first case (which is altering Reno's behavior),
> parallelism can gain something. But the same can better be gained by
> changing the congestion control algorithm. This is confusing.
>
> If the first case is about changing Reno's behavior, I am unsure why you
> said "it could more cleanly be gained by changing the congestion control
> algorithm of a single flow" compared to using the parallelism.
>
> Best regards,
> Zartash
>
> -----Original Message-----
> From: Lachlan Andrew [mailto:lachlan.andrew at gmail.com]
> Sent: Monday, April 05, 2010 3:41 AM
> To: Zartash Afzal Uzmi
> Cc: tim at ivisit.com; end2end-interest at postel.org
> Subject: Re: [e2e] TCP goodput as a function of connection count
>
> Greetings Zartash,
>
> AFAIK, multiple flows in download accelerators benefit their users
> using the two mechanisms I mentioned in the final paragraph of my
> email.  (a) On high bandwidth-delay product (BDP) paths with frequent
> transient loss/congestion, they can overcome Reno's slow increase and
> rapid decrease in rate, and (b) they can give their users more rate at
> the expense of other users.
>
> In the first case, something is gained by parallelism, but it could
> more cleanly be gained by changing the congestion control algorithm of
> a single flow.  In the latter case, I'd argue that nothing is gained
> by the community as a whole, although of course something is gained by
> the one with parallel flows.
>
> This is just my understanding; I'd be happy to be corrected.
>
> Cheers,
> Lachlan
>
> On 5 April 2010 08:05, Zartash Afzal Uzmi <zartash at lums.edu.pk> wrote:
>> Hi Lachlan,
>>
>> Theoretically, what you mentioned makes good sense: it is convincing that
>> bittorrent's benefit is realized by working with multiple paths and not
> just
>> multiple connections. Practically, we do see simultaneous tcp connections
>> bring benefit to the end user (in download accelerators, for example).
> These
>> connections aren't on different paths, yet the end user benefits. Is that
>> not contrary to the original intuition that nothing is gained by
>> parallelism?
>>
>> Best regards,
>> Zartash
>>
>> -----Original Message-----
>> From: end2end-interest-bounces at postel.org
>> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Lachlan Andrew
>> Sent: Sunday, April 04, 2010 3:07 AM
>> To: tim at ivisit.com
>> Cc: end2end-interest at postel.org
>> Subject: Re: [e2e] TCP goodput as a function of connection count
>>
>> Greetings Tim,
>>
>> On a quick scan, the "TCP connection game" paper seems to deal with
>> opening multiple connections over a single path.  The only benefits
>> that generally gives are (a) working around Reno's inability to fill
>> the path, and (b) providing a mechanism for unequal sharing of
>> capacity.  The (social) benefit from bittorrent is the multiple paths,
>> not just multiple connections.
>
>
> --
> Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
> Swinburne University of Technology, Melbourne, Australia
> <http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
> Ph +61 3 9214 4837
>
>
>

-- 
Vimal
http://www.stanford.edu/~jvimal