From tim at ivisit.com  Sat Apr  3 11:45:41 2010
From: tim at ivisit.com (Tim Dorcey)
Date: Sat, 3 Apr 2010 10:45:41 -0800
Subject: [e2e] TCP goodput as a function of connection count
Message-ID: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>

Is anyone aware of theoretical or empirical results regarding tcp goodput as
function of the number of independent tcp connections sharing a link?  I
have seen arguments in favor of the increased parallelism that distributed
transports like bittorrent offer.  But, what does parallelism buy in a
time-sharing environment?  I would expect nothing is gained by 10
simultaneous file transfers each using 10% of 10 different paths, versus
each using 100% of its own path.

Taking this argument a little further is TCP biased toward too much
fairness?  If there are 10 equal size "jobs" to be done, doing them in
parallel insures that none complete sooner than the worst case if they were
done sequentially.  I guess given mix of big and small jobs, perhaps not
much is lost by treating everything as small job?

Tim


From sadoc at cs.umass.edu  Sat Apr  3 12:48:48 2010
From: sadoc at cs.umass.edu (Daniel S. Menasche)
Date: Sat, 03 Apr 2010 15:48:48 -0400
Subject: [e2e] TCP goodput as a function of connection count
In-Reply-To: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>
References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>
Message-ID: <1270324128.28784.171.camel@copa.office.umasshillel.org>

Dear Tim,

On the theoretical side, this work is related,

Honggang Zhang, Don Towsley, Weibo Gong, "TCP Connection Game: A Study
on the Selfish Behavior of TCP Users", Proceedings of IEEE ICNP 2005

Maybe among  its references, or among the papers that cite it, we can
find some answers to your questions.

Best regards, Daniel




On Sat, 2010-04-03 at 10:45 -0800, Tim Dorcey wrote:
> Is anyone aware of theoretical or empirical results regarding tcp goodput as
> function of the number of independent tcp connections sharing a link?  I
> have seen arguments in favor of the increased parallelism that distributed
> transports like bittorrent offer.  But, what does parallelism buy in a
> time-sharing environment?  I would expect nothing is gained by 10
> simultaneous file transfers each using 10% of 10 different paths, versus
> each using 100% of its own path.
> 
> Taking this argument a little further is TCP biased toward too much
> fairness?  If there are 10 equal size "jobs" to be done, doing them in
> parallel insures that none complete sooner than the worst case if they were
> done sequentially.  I guess given mix of big and small jobs, perhaps not
> much is lost by treating everything as small job?
> 
> Tim


From lachlan.andrew at gmail.com  Sat Apr  3 15:07:08 2010
From: lachlan.andrew at gmail.com (Lachlan Andrew)
Date: Sun, 4 Apr 2010 08:07:08 +1000
Subject: [e2e] TCP goodput as a function of connection count
In-Reply-To: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>
References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>
Message-ID: <u2xaa7d2c6d1004031507g69e7b99do6bc39a63da27a61c@mail.gmail.com>

Greetings Tim,

On 4 April 2010 04:45, Tim Dorcey <tim at ivisit.com> wrote:
> I have seen arguments in favor of the increased parallelism that distributed
> transports like bittorrent offer. ?But, what does parallelism buy in a
> time-sharing environment? ?I would expect nothing is gained by 10
> simultaneous file transfers each using 10% of 10 different paths, versus
> each using 100% of its own path.

If all 10 user shared exactly the same 10 paths, then your intuition
holds.  The theoretical benefit to multipath TCP is that each path is
typically shared with   different   numbers of users.  Each user can
explore multiple paths to find the ones which are shared with fewer
users, and send more data on those less-busy paths.  Thus, it is a
form of distributed traffic engineering.  Frank Kelly, Thomas Voice
and Peter Key have all done theoretical work in that area.

The practical benefits of multipath TCP are entirely different, like
robustness to disconnection.

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.

Cheers,
Lachlan

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


From zartash at lums.edu.pk  Sun Apr  4 15:05:56 2010
From: zartash at lums.edu.pk (Zartash Afzal Uzmi)
Date: Mon, 5 Apr 2010 03:05:56 +0500
Subject: [e2e] TCP goodput as a function of connection count
In-Reply-To: <u2xaa7d2c6d1004031507g69e7b99do6bc39a63da27a61c@mail.gmail.com>
References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>
	<u2xaa7d2c6d1004031507g69e7b99do6bc39a63da27a61c@mail.gmail.com>
Message-ID: <003001cad443$0071b630$01552290$@edu.pk>

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 4 April 2010 04:45, Tim Dorcey <tim at ivisit.com> wrote:
> I have seen arguments in favor of the increased parallelism that
distributed
> transports like bittorrent offer. ?But, what does parallelism buy in a
> time-sharing environment? ?I would expect nothing is gained by 10
> simultaneous file transfers each using 10% of 10 different paths, versus
> each using 100% of its own path.

If all 10 user shared exactly the same 10 paths, then your intuition
holds.  The theoretical benefit to multipath TCP is that each path is
typically shared with   different   numbers of users.  Each user can
explore multiple paths to find the ones which are shared with fewer
users, and send more data on those less-busy paths.  Thus, it is a
form of distributed traffic engineering.  Frank Kelly, Thomas Voice
and Peter Key have all done theoretical work in that area.

The practical benefits of multipath TCP are entirely different, like
robustness to disconnection.

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.

Cheers,
Lachlan

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




From lachlan.andrew at gmail.com  Sun Apr  4 15:41:25 2010
From: lachlan.andrew at gmail.com (Lachlan Andrew)
Date: Mon, 5 Apr 2010 08:41:25 +1000
Subject: [e2e] TCP goodput as a function of connection count
In-Reply-To: <003001cad443$0071b630$01552290$@edu.pk>
References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com> 
	<u2xaa7d2c6d1004031507g69e7b99do6bc39a63da27a61c@mail.gmail.com> 
	<003001cad443$0071b630$01552290$@edu.pk>
Message-ID: <m2qaa7d2c6d1004041541n560ce655p6488dbd2d43fa953@mail.gmail.com>

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


From jasleen at cs.unc.edu  Sun Apr  4 19:25:59 2010
From: jasleen at cs.unc.edu (Jasleen Kaur)
Date: Sun, 04 Apr 2010 22:25:59 -0400
Subject: [e2e] Internet packet loss rates
In-Reply-To: <4BA025AD.9040501@cis.udel.edu>
References: <4BA025AD.9040501@cis.udel.edu>
Message-ID: <4BB94A37.700@cs.unc.edu>


Paul,

Our 2007 paper on TCP loss detection/recovery mechanisms includes 
statistics on loss rates (observed passively) in nearly 3 million 
Internet TCP transfers:

S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss 
Detection/Recovery in Real-world TCP Implementations" 
<http://www.cs.unc.edu/%7Ejasleen/papers/icnp07.pdf>, in Proceedings of 
the IEEE International Conference on Network Protocols (ICNP'07), 
Beijing, China, Oct 2007.

- Jasleen



Paul D. Amer wrote:
> Does anyone know of recent studies empirically
> measuring Internet packet loss rates/distributions?
> Thanks,
> Paul Amer
> Univ of Delaware
>

From zartash at lums.edu.pk  Sun Apr  4 20:48:50 2010
From: zartash at lums.edu.pk (Zartash Afzal Uzmi)
Date: Mon, 5 Apr 2010 08:48:50 +0500
Subject: [e2e] TCP goodput as a function of connection count
In-Reply-To: <m2qaa7d2c6d1004041541n560ce655p6488dbd2d43fa953@mail.gmail.com>
References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com>
	<u2xaa7d2c6d1004031507g69e7b99do6bc39a63da27a61c@mail.gmail.com>
	<003001cad443$0071b630$01552290$@edu.pk>
	<m2qaa7d2c6d1004041541n560ce655p6488dbd2d43fa953@mail.gmail.com>
Message-ID: <002201cad472$e7507350$b5f159f0$@edu.pk>

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



From j.vimal at gmail.com  Sun Apr  4 21:33:10 2010
From: j.vimal at gmail.com (Vimal)
Date: Sun, 4 Apr 2010 21:33:10 -0700
Subject: [e2e] TCP goodput as a function of connection count
In-Reply-To: <002201cad472$e7507350$b5f159f0$@edu.pk>
References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com> 
	<u2xaa7d2c6d1004031507g69e7b99do6bc39a63da27a61c@mail.gmail.com> 
	<003001cad443$0071b630$01552290$@edu.pk>
	<m2qaa7d2c6d1004041541n560ce655p6488dbd2d43fa953@mail.gmail.com>
	<002201cad472$e7507350$b5f159f0$@edu.pk>
Message-ID: <h2zff71fbf21004042133l94bdd609n7512761e17c68327@mail.gmail.com>

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


From cottrell at slac.stanford.edu  Mon Apr  5 08:03:02 2010
From: cottrell at slac.stanford.edu (Cottrell, Les)
Date: Mon, 5 Apr 2010 08:03:02 -0700
Subject: [e2e] Internet packet loss rates
In-Reply-To: <4BB94A37.700@cs.unc.edu>
References: <4BA025AD.9040501@cis.udel.edu> <4BB94A37.700@cs.unc.edu>
Message-ID: <396BAB878F9AAD419E686BB95EF9EEED01215D58E49E@EXCHCLUSTER1-01.win.slac.stanford.edu>

Though not a study there is a lot of data on Internet Packet losses going back over 12 years in the PingER project (see the site map at http://www-iepm.slac.stanford.edu/pinger/). In this about 40 monitoring stations in about 15 countries monitor every 30 mins the ping RTTs, losses, jitter etc. to over 700 sites in over 150 countries. The analyzed data is available and downloadable from http://www-wanmon.slac.stanford.edu/cgi-wrap/pingtable.pl. From this form you can choose your metric the sources of the pings, the destination, the aggregation time as well as various affinity groups for aggregation. 

Bear in mind that since only 10 pings are done each 30 mins, even aggregating over 1 year (48 measurement intervals of 30 mins each / day * 365 days) ping loss rates of less than 1  in 175K cannot be observed. However, the losses are good for developing nations.

A recent report at http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan10/report-jan10.doc does include some analysis of losses (see Fig 7). Earlier reports had more information on losses, see Figs 4, 5, 6, 7, 8 in http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan09/report-jan09.doc

> -----Original Message-----
> From: end2end-interest-bounces at postel.org [mailto:end2end-interest-
> bounces at postel.org] On Behalf Of Jasleen Kaur
> Sent: Sunday, April 04, 2010 7:26 PM
> To: Paul D. Amer
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] Internet packet loss rates
> 
> 
> Paul,
> 
> Our 2007 paper on TCP loss detection/recovery mechanisms includes
> statistics on loss rates (observed passively) in nearly 3 million
> Internet TCP transfers:
> 
> S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss
> Detection/Recovery in Real-world TCP Implementations"
> <http://www.cs.unc.edu/%7Ejasleen/papers/icnp07.pdf>, in Proceedings of
> the IEEE International Conference on Network Protocols (ICNP'07),
> Beijing, China, Oct 2007.
> 
> - Jasleen
> 
> 
> 
> Paul D. Amer wrote:
> > Does anyone know of recent studies empirically
> > measuring Internet packet loss rates/distributions?
> > Thanks,
> > Paul Amer
> > Univ of Delaware
> >


From dpreed at reed.com  Mon Apr  5 09:23:43 2010
From: dpreed at reed.com (David P. Reed )
Date: Mon, 05 Apr 2010 09:23:43 -0700
Subject: [e2e] Internet packet loss rates
Message-ID: <ml8e5ccls0iphd1vxowk9k8b.1270484623463@email.android.com>

Given that internet packets are lost by a process that is not primarily associated with path, but with usage by others, such numbers may be nearly meaning-free. Without usage statistics for the same period, and knowledge of the queueing parameters of packet switches in paths, what can one say?

If you got a data sequence that looked like the first million bits of pi, but had no access to know what process purported to generate those drops, what value would those bits have?

It would be entirely shaped by your fantasy of what the system did.

And in this case, YOU DON'T KNOW ENOUGH!

"Cottrell, Les" <cottrell at slac.stanford.edu> wrote:

>Though not a study there is a lot of data on Internet Packet losses going back over 12 years in the PingER project (see the site map at http://www-iepm.slac.stanford.edu/pinger/). In this about 40 monitoring stations in about 15 countries monitor every 30 mins the ping RTTs, losses, jitter etc. to over 700 sites in over 150 countries. The analyzed data is available and downloadable from http://www-wanmon.slac.stanford.edu/cgi-wrap/pingtable.pl. From this form you can choose your metric the sources of the pings, the destination, the aggregation time as well as various affinity groups for aggregation. 
>
>Bear in mind that since only 10 pings are done each 30 mins, even aggregating over 1 year (48 measurement intervals of 30 mins each / day * 365 days) ping loss rates of less than 1  in 175K cannot be observed. However, the losses are good for developing nations.
>
>A recent report at http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan10/report-jan10.doc does include some analysis of losses (see Fig 7). Earlier reports had more information on losses, see Figs 4, 5, 6, 7, 8 in http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan09/report-jan09.doc
>
>> -----Original Message-----
>> From: end2end-interest-bounces at postel.org [mailto:end2end-interest-
>> bounces at postel.org] On Behalf Of Jasleen Kaur
>> Sent: Sunday, April 04, 2010 7:26 PM
>> To: Paul D. Amer
>> Cc: end2end-interest at postel.org
>> Subject: Re: [e2e] Internet packet loss rates
>> 
>> 
>> Paul,
>> 
>> Our 2007 paper on TCP loss detection/recovery mechanisms includes
>> statistics on loss rates (observed passively) in nearly 3 million
>> Internet TCP transfers:
>> 
>> S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss
>> Detection/Recovery in Real-world TCP Implementations"
>> <http://www.cs.unc.edu/%7Ejasleen/papers/icnp07.pdf>, in Proceedings of
>> the IEEE International Conference on Network Protocols (ICNP'07),
>> Beijing, China, Oct 2007.
>> 
>> - Jasleen
>> 
>> 
>> 
>> Paul D. Amer wrote:
>> > Does anyone know of recent studies empirically
>> > measuring Internet packet loss rates/distributions?
>> > Thanks,
>> > Paul Amer
>> > Univ of Delaware
>> >
>


From L.Wood at surrey.ac.uk  Tue Apr  6 12:20:21 2010
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 6 Apr 2010 20:20:21 +0100
Subject: [e2e] Internet packet loss rates
In-Reply-To: <ml8e5ccls0iphd1vxowk9k8b.1270484623463@email.android.com>
References: <ml8e5ccls0iphd1vxowk9k8b.1270484623463@email.android.com>
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A37305A1ACDE88@EXMB01CMS.surrey.ac.uk>

David P. Reed wrote:
> Without usage statistics for the same period, and knowledge
> of the queueing parameters of packet switches in paths, what
> can one say?

Perhaps one can construct something like the fantasy built on
http://www.postel.org/pipermail/end2end-interest/2009-September/007742.html
based on a single sample set?

> It would be entirely shaped by your fantasy of what the system did.
>
> And in this case, YOU DON'T KNOW ENOUGH!

Well, yes. But what's wrong with speculation based on evidence?

"Measurements are never perfect, but that doesn't mean they can't tell us 
a lot." -- D. P. Reed, 7 Sep 2009.

-----Original Message-----
From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of David P. Reed 
Sent: 05 April 2010 17:24
To: Cottrell, Les; Jasleen Kaur; Paul D. Amer
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Internet packet loss rates

Given that internet packets are lost by a process that is not primarily associated with path, but with usage by others, such numbers may be nearly meaning-free. Without usage statistics for the same period, and knowledge of the queueing parameters of packet switches in paths, what can one say?

If you got a data sequence that looked like the first million bits of pi, but had no access to know what process purported to generate those drops, what value would those bits have?

It would be entirely shaped by your fantasy of what the system did.

And in this case, YOU DON'T KNOW ENOUGH!

"Cottrell, Les" <cottrell at slac.stanford.edu> wrote:

>Though not a study there is a lot of data on Internet Packet losses going back over 12 years in the PingER project (see the site map at http://www-iepm.slac.stanford.edu/pinger/). In this about 40 monitoring stations in about 15 countries monitor every 30 mins the ping RTTs, losses, jitter etc. to over 700 sites in over 150 countries. The analyzed data is available and downloadable from http://www-wanmon.slac.stanford.edu/cgi-wrap/pingtable.pl. From this form you can choose your metric the sources of the pings, the destination, the aggregation time as well as various affinity groups for aggregation. 
>
>Bear in mind that since only 10 pings are done each 30 mins, even aggregating over 1 year (48 measurement intervals of 30 mins each / day * 365 days) ping loss rates of less than 1  in 175K cannot be observed. However, the losses are good for developing nations.
>
>A recent report at 
>http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan10/report-jan1
>0.doc does include some analysis of losses (see Fig 7). Earlier reports 
>had more information on losses, see Figs 4, 5, 6, 7, 8 in 
>http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan09/report-jan0
>9.doc
>
>> -----Original Message-----
>> From: end2end-interest-bounces at postel.org [mailto:end2end-interest- 
>> bounces at postel.org] On Behalf Of Jasleen Kaur
>> Sent: Sunday, April 04, 2010 7:26 PM
>> To: Paul D. Amer
>> Cc: end2end-interest at postel.org
>> Subject: Re: [e2e] Internet packet loss rates
>> 
>> 
>> Paul,
>> 
>> Our 2007 paper on TCP loss detection/recovery mechanisms includes 
>> statistics on loss rates (observed passively) in nearly 3 million 
>> Internet TCP transfers:
>> 
>> S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss 
>> Detection/Recovery in Real-world TCP Implementations"
>> <http://www.cs.unc.edu/%7Ejasleen/papers/icnp07.pdf>, in Proceedings 
>> of the IEEE International Conference on Network Protocols (ICNP'07), 
>> Beijing, China, Oct 2007.
>> 
>> - Jasleen
>> 
>> 
>> 
>> Paul D. Amer wrote:
>> > Does anyone know of recent studies empirically measuring Internet 
>> > packet loss rates/distributions?
>> > Thanks,
>> > Paul Amer
>> > Univ of Delaware
>> >
>



From paalh at ifi.uio.no  Sat Apr 10 23:59:18 2010
From: paalh at ifi.uio.no (=?iso-8859-1?Q?P=E5l_Halvorsen?=)
Date: Sun, 11 Apr 2010 08:59:18 +0200
Subject: [e2e] NOSSDAV 2010 CALL FOR PARTICIPATION
Message-ID: <07420F80-12EE-46B4-9055-1C6355C4CCA9@ifi.uio.no>


** NOSSDAV 2010 CALL FOR PARTICIPATION **

Nossdav 2010
Amsterdam, The Netherlands. June 2-4, 2010
http://www.nossdav.org/2010/

We invite you to attend NOSSDAV 2010 which is SIGMM's leading workshop
on network and operating systems support for digital audio and
video. The workshop, hosted by the Centrum Wiskunde & Informatica
(CWI) covers emerging research topics, controversial ideas and future
research directions in the area of multimedia systems research.

*** Program (or see below): 
http://www.nossdav.org/2010/program.html

*** Registration:
http://www.nossdav.org/2010/register.html

Please note:
- deadline for discounted early registration (May 8th)
- deadline for booking a room at hotel NH Tropen (April 21st)



NOSSDAV 2010 PROGRAM:
=====================

*** June 2, 2010 ***

1800 Registration Opens

1900 Reception

*** June 3, 2010 ***

0800 - 0830 Registration and Breakfast

0830 - 0845 Welcome

0845 - 1000 Keynote Speech

1000 - 1030 Coffee Break

1030 - 1200 Session 1: Social Networking

- Second Life In-World Action Traffic Modeling
- Second Life: a Social Network of Humans and Bots
- Tweeting Videos: Coordinate Live Streaming and Storage Sharing

1200 - 1330 Lunch

1330 - 1500 Session 2:  Multimedia and P2P Streaming

- Quality-Adaptive Scheduling for Live Streaming over Multiple Access Networks
- Mesh-based Peer-to-Peer Layered Video Streaming With Taxation
- Reducing Data Request Contentions for Improved Streaming Quality

1500 - 1530 Coffee Break

1530 - 1730 Session 3:  3D and Immersive Environments

- TSync: A New Synchronization Framework for Multi-site 3D Tele-immersion
- Video Indexed VM Continuous Checkpoints: Time Travel Support for
Virtual 3D Graphics Applications 
- TriggerTV: Exploiting Social User Journeys within an Interactive TV System

1900 Banquet    


*** June 4, 2010 ***

0800 - 0830 Registration and Breakfast

0830 - 1000 Session 4: Quality Assessment and Measurement

- A New QoE Model and Evaluation Method for Broadcast Audio Contribution over IP
- Randomised Pair Comparison - An Economic and Robust Method for
Audiovisual Quality Assessment 
- The Implication of External links on Video Sharing Sites: Measurement
and Analysis 

1000 - 1030 Coffee Break

1030 - 1200 Session 5: GPU and Multicore Systems 

- Tips, Tricks and Troubles: Optimizing for Cell and GPU
- p264: Open Platform for Designing Parallel H.264/AVC Video Encoders on
Multi-Core Systems 
- RTP-Miner: an Efficient Online Intrusion Detection Framework for
Detecting RTP Fuzzing Attacks  

1200 - 1330 Lunch

1330 - 1500 Session 6: Peer-to-Peer Streaming 

- Designing a Tit-for-Tat Based Peer-to-Peer Video-on-Demand System
- Caching and Request Generation for a Peer-based PVR
- Collaborative Delay-Aware Scheduling in Peer-to-Peer UGC Video Sharing

1500 - 1530 Coffee Break

1530 - 1700 Session 7: Wireless and Mesh Streaming 

- Performance Analysis of Home Streaming Video Using Orb
- On wireless network interface energy conservation for bottlenecked
first mile network 
- Towards Understanding User Tolerance to Network Latency and Data Rate
in Remote Viewing of Progressive Meshes 

1700 - 1715 Concluding Remarks



From mallman at icir.org  Tue Apr 13 07:40:35 2010
From: mallman at icir.org (Mark Allman)
Date: Tue, 13 Apr 2010 10:40:35 -0400
Subject: [e2e] IMC 2010 CFP
Message-ID: <20100413144035.74E84D96B65@lawyers.icir.org>


[Folks- a quick reminder that the IMC deadline is coming up.  Please
 do consider submitting.  --allman (IMC 2010 PC chair)]


Internet Measurement Conference (IMC) 2010
November 1 - 3, 2010
Melbourne, Australia

The tenth Internet Measurement Conference is a three day event
focusing on Internet measurement and analysis, building on the
success of past IMCs. We invite submissions of papers that
contribute to our understanding of the Internet's structure and
behavior, as well as methods to collect or analyze Internet
measurements.

IMC accepts two kinds of papers:

  - Full papers (up to 14 two-column pages) describing original
    research, with succinctness appropriate to the topics and themes
    they discuss. 
  - Short papers (up to 6 two-column pages for text and figures + 1
    page for references) conveying work that is less mature but
    shows promise, articulating a high-level vision, describing
    challenging future directions, critiquing current measurement
    wisdom or offering results that do not merit a full submission.

Key dates:

  - May 10, 2010: 8AM EDT: Registration of title and 250-word
                           abstract 
  - May 17, 2010: 8AM EDT: HARD submission deadline
  - July 28, 2010:         Notification
  - November 1-3, 2010:    Conference held in Melbourne, Australia

Please see the full CFP here:

  http://conferences.sigcomm.org/imc/2010/cfp.html

for full details.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20100413/b11e139d/attachment.bin

From pippobox at gmail.com  Sat Apr 17 20:32:35 2010
From: pippobox at gmail.com (pippo0729 ads)
Date: Sun, 18 Apr 2010 11:32:35 +0800
Subject: [e2e] Narada: what does the "refresh message" mean?
Message-ID: <q2i2d129fe61004172032t15622bedy8abb594e630f9240@mail.gmail.com>

Hi everyone, I'm currently learning p2p essentials(routing overlay,
application layer multicast schemes, etc.) and choose narada as my first
studying material. Now, I have a question about the refresh message
mentioned in the paper "A Case for End System Multicast" ------ what is the
content of the message? only the sequence number or the list of entry that
represent the group membership or both ?

Several places in the paper metioning the notion "refresh message" which I'm
confused of are:
1) paragraph two of section III-A : "To handle this, we require that each
member periodically generate a *refresh message* with monotonically
increasing sequence number,
which is disseminated along the mesh." ------ I think it refer to a message
containing only sequence number here
2) figure 3. and its description: "Actions taken by a member i on receiving
a refresh message from member j." ------ I think it refer to a message
containing a list representing the group member ship here.
Seems contradictory in these places, so what does "refresh message" really
mean?

by the way, does any one have an implementation of narada?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20100418/2295a7ab/attachment.html

From sds at dcs.gla.ac.uk  Sun Apr 18 08:52:51 2010
From: sds at dcs.gla.ac.uk (Stephen Strowes)
Date: Sun, 18 Apr 2010 16:52:51 +0100
Subject: [e2e] Narada: what does the "refresh message" mean?
In-Reply-To: <q2i2d129fe61004172032t15622bedy8abb594e630f9240@mail.gmail.com>
References: <q2i2d129fe61004172032t15622bedy8abb594e630f9240@mail.gmail.com>
Message-ID: <1271605971.5050.5.camel@Nokia-N900-42-11>

----- Original message -----
> Now, I have a question about the refresh message mentioned in the paper "A Case
> for End System Multicast" ------ what is the content of the message? only the
> sequence number or the list of entry that represent the group membership or both
> ?
>
> Several places in the paper metioning the notion "refresh message" which I'm
> confused of are: 1) paragraph two of section III-A : "To handle this, we require
> that each member periodically generate a refresh message with monotonically
> increasing sequence number, which is disseminated along the mesh." ------ I
> think it refer to a message containing only sequence number here 2) figure 3.
> and its description: "Actions taken by a member i on receiving a refresh message
> from member j." ------ I think it refer to a message containing a list
> representing the group member ship here. Seems contradictory in these places, so
> what does "refresh message" really mean?

It's not contradictory. The paragraph in S.III-A simply doesn't describe the full contents of a packet.

- Every group member periodically generates a message containing it's identity (IP address, perhaps), and a counter.
- Each peer periodically sends a list of origin:counter pairs to its neighbours.

It doesn't take much of a leap for each peer to issue one message regularly which satisfies the algorithm.

Remember that although the mesh is not fully connected, each peer maintains state referring to all other group members. So while refresh messages are exchanged between /neighbours/, the messages may contain information about the whole group.


> by the way, does any one have an implementation of narada?

I couldn't find any when I looked a few years ago. Though I did work on a link-state variant of Narada, called Orta, and you should still be able to pull the source code for that from here: http://svn.sdstrowes.co.uk/


Cheers,
-S.

________________________________
The University of Glasgow, charity number SC004401
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20100418/ed3fb0b4/attachment.html

From m.garcia.upv at gmail.com  Tue Apr 27 11:22:36 2010
From: m.garcia.upv at gmail.com (Miguel Garcia)
Date: Tue, 27 Apr 2010 20:22:36 +0200
Subject: [e2e] Last Mile || InfoWare 2010 [ICCGI, ICWMC, INTERNET,
	ACCESS] September 20-25, 2010 - Valencia, Spain
Message-ID: <201004271822.o3RIMaF8009776@smtp.upv.es>


INVITATION

Note that we are entering the last few days to submit work to one of the 
InfoWare 2010 events. Please consider to contribute and encourage your 
team members and fellow scientists to contribute to the following 
federated events.

The submission deadline is April 30, 2010.

Publisher: CPS ( see: http://www2.computer.org/portal/web/cscps )
Archived: IEEE CSDL (Computer Science Digital Library) and IEEE Xplore
Submitted for indexing: Elsevier's EI Compendex Database, EI?s 
Engineering Information Index

Thanks for forwarding the information on this Call for Submissions to 
those potentially interested to submit.

===== Call for Submissions =======

InfoWare 2010, September 20-25, 2010 - Valencia, Spain
see: http://www.iaria.org/conferences2010/InfoWare10.html

InfoWare 2010 is a federated event focusing on advances topics 
concerning information technology, wireless, mobile communications, 
internet, and network access. InfoWare 2010 continues the tradition of 
well-established conferences ICCGI and ICWMC, while complementing the 
topics with INTERNET and ACCESS.

Submission (full paper) new deadline: April 30, 2010.

Submissions must be electronically done using the 'Submit a Paper' link 
on the entry page of each conference.

Before submission, please check and conform with the Editorial rules:
http://www.iaria.org/editorialrules.html.

For details on the each conference's topics, see the individual Call for 
Papers for each conference.

Unpublished high quality contributions in terms of Regular papers and 
Posters or Work in Progress are welcome. Workshop proposals and Panel 
proposals on challenging topics are encouraged.

Extended versions of selected papers will be published in IARIA on-line 
Journals (http://www.iariajournals.org) and in Special issues of 
different journals mentioned on the entry page of each conference.

Submissions will be peer-reviewed, published by IEEE Computer Society 
Press, posted in IEEE Digital Library, and indexed via all the IEEE 
indexing agreements.

All tracks/topics are open to both research and industry contributions.

-- ICCGI 2010, The Fifth International Multi-Conference on Computing in 
the Global Information Technology
http://www.iaria.org/conferences2010/ICCGI10.html

-- ICWMC 2010, The Sixth International Conference on Wireless and Mobile 
Communications
http://www.iaria.org/conferences2010/ICWMC10.html

-- INTERNET 2010, The Second International Conference on Evolving Internet
http://www.iaria.org/conferences2010/INTERNET10.html

-- ACCESS 2010, The First International Conferences on Access Networks, 
Services and Technologies
http://www.iaria.org/conferences2010/ACCESS10.html


-----------------------
Conferences' Chairs
IARIA Publicity Board
-----------------------

From touch at ISI.EDU  Wed Apr 28 08:48:32 2010
From: touch at ISI.EDU (Joe Touch)
Date: Wed, 28 Apr 2010 08:48:32 -0700
Subject: [e2e] reminder about postings of call for papers, participations,
	and extensions
Message-ID: <4BD858D0.5030504@isi.edu>

Hi, all,

We are continuing to receive a number of non-preapproved calls for
papers, participation, and notices of extension to this list, some of
which are getting through the filters (yesterday's post by Miguel
Garcia, e.g.).

A reminder to all subscribers:

	- *ALL* CFPs must be approved *in advance*

	- repeated announcements or reminders are NOT PERMITTED
		this includes extension notices

Please review the list policies before posting. They can be found at:
http://www.postel.org/e2e.htm#policies

Joe (list admin)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20100428/1bc2826c/signature.bin