Subject: [multipathtcp] More general congestion control linking

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 Aug 2009 11:18:54 +0200

Hi,

After reading some of the mailinglist discussions, it occurs to me  
that linking congestion control state isn't only useful between  
subflows belonging to the same multipath TCP session, but could also  
be applied to separate TCP flows between two hosts (think parallel  
connections to the same HTTP server) or even TCP flows towards  
different destinations (such as with BitTorrent).

Iljitsch

---

From: "Joerg Wagner" <[email-masked]>
Date: Fri, 7 Aug 2009 14:09:36 +0200

> connections to the same HTTP server)
One could come up with a counter-scenario regarding "user-experience"...
Imagine you browse to a website providing text and some (data intensive) images. I prefer having the text quickly and I am willing to wait for the picture a little bit longer. If a coupled transfer would slow-down the textual data (but result in an overall gain though) I would be disappointed.

> or even TCP flows towards
Maybe here one must differentiate a little bit. Having these flows compete against each other seems rather odd too, but a competition against other applications could still be useful (and probably should be regulated by the end-user).
The question is how one can decide where the bottleneck is? E.g. competition of flows belonging to the same application on a saturated homegateway makes not much sense (because it wastes packets) but if the bottleneck is located later on some of the (divergent) paths the flows should certainly try to adjust to that situation. Can we assume the homegateway to be the bottleneck always?

In any case wouldn't an implementation automatically result in the need to provide more "internet connection options" to the end-user just to fulfill all possible wishes? 

Joerg

---

From: Lars Eggert <[email-masked]>
Date: Sat, 8 Aug 2009 10:52:14 +0300

RFC2140

RFC3124

Effects of Ensemble-TCP. Lars Eggert, John Heidemann and Joe Touch.  
ACM Computer Communication Review (CCR), Vol. 30, No. 1, January 2000,  
pp. 15-29. https://fit.nokia.com/lars/papers/ensemble-tcp.pdf

Lars

On 2009-8-7, at 12:18, Iljitsch van Beijnum wrote:

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Lars Eggert <[email-masked]>
Date: Sat, 8 Aug 2009 10:54:06 +0300

Hi,

On 2009-8-7, at 15:09, Joerg Wagner wrote:
> Imagine you browse to a website providing text and some (data  
> intensive) images. I prefer having the text quickly and I am willing  
> to wait for the picture a little bit longer. If a coupled transfer  
> would slow-down the textual data (but result in an overall gain  
> though) I would be disappointed.

see the results for the "HTML-pre" scheme in https://fit.nokia.com/lars/papers/ensemble-tcp.pdf

Lars

> Maybe here one must differentiate a little bit. Having these flows  
> compete against each other seems rather odd too, but a competition  
> against other applications could still be useful (and probably  
> should be regulated by the end-user).
> The question is how one can decide where the bottleneck is? E.g.  
> competition of flows belonging to the same application on a  
> saturated homegateway makes not much sense (because it wastes  
> packets) but if the bottleneck is located later on some of the  
> (divergent) paths the flows should certainly try to adjust to that  
> situation. Can we assume the homegateway to be the bottleneck always?
>
> In any case wouldn't an implementation automatically result in the  
> need to provide more "internet connection options" to the end-user  
> just to fulfill all possible wishes?
>
> Joerg

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Aug 2009 12:03:46 +1200

I've been wondering how experience with GridFTP relates to all
this. Googling for gridftp performance congestion gives quite
a few interesting results, including
http://damsl.cis.udel.edu/projects/phoebus/phoebus_gridftp.pdf

There are measurements on some serious running code there.

   Brian