[e2e] TCP goodput as a function of connection count

[Zartash Afzal Uzmi]

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