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: Greetings Tim, On 4 April 2010 04:45, Tim Dorcey 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 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: References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.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 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 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> <003001cad443$0071b630$01552290$@edu.pk> Message-ID: 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 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 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" , 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: References: <071301cad35d$dd8a7b60$0200a8c0@int.eyematic.com> <003001cad443$0071b630$01552290$@edu.pk> 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 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 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> <003001cad443$0071b630$01552290$@edu.pk> <002201cad472$e7507350$b5f159f0$@edu.pk> Message-ID: 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 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 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 > > 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" > , 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: 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" 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" >> , 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: References: Message-ID: 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" 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" >> , 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: 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: References: 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