Private:Random - Revision history

MediaWiki default at 23:14, 13 December 2009

2009-12-13T23:14:57Z

MediaWiki default at 23:14, 13 December 2009

2009-12-13T23:14:24Z

MediaWiki default at 05:09, 5 March 2009

2009-03-05T05:09:00Z

MediaWiki default at 05:06, 5 March 2009

2009-03-05T05:06:21Z

MediaWiki default at 04:54, 5 March 2009

2009-03-05T04:54:57Z

MediaWiki default at 19:59, 21 November 2008

2008-11-21T19:59:09Z

142.58.185.118 at 16:42, 6 August 2008

2008-08-06T16:42:38Z

142.58.185.118 at 16:42, 6 August 2008

2008-08-06T16:42:25Z

MediaWiki default at 22:57, 7 March 2008

2008-03-07T22:57:54Z

MediaWiki default at 22:55, 7 March 2008

2008-03-07T22:55:47Z

← Older revision		Revision as of 23:14, 13 December 2009
Line 4:		Line 4:
	== Transport Protocol for Asymmetric Communication ==		== Transport Protocol for Asymmetric Communication ==

−	[Cheng 11/13/2009] Unfortunately, the number of bits need to be sent by a client is no less than the binary entropy of the symbol distribution (following Shannon's theorem). Adler and Maggs' protocol assumes that the server knows the symbol distribution, and shows how the server can help the client (who doesn't know the distribution) to efficiently transmit the data. Their protocol does not lead to fewer number of bits transmitted by the client, compared to the common scenario where the client knows the symbol distribution. Therefore, this protocol (as well as several other extensions based on it) does not reduce the upstream bandwidth requirement. On the other hand, while Gagie's protocol does not rely on the assumption that the server has the symbol distribution, it does not result in better performance (in terms of number of bits sent by clients), when there is a single client/sender in the data transmission. That is, it has to leverage on correlations among data sent by multiple clients to achieve better compression ratio. In summary, existing protocols are only applicable in very few scenarios/applications. I believe the only practically useful scenario is solving bandwidth asymmetry in P2P networks. And even in that application, it's not clear whether it's worth to deploy servers to help peers utilize their upstream bandwidths. (Why not using the resources to send the content directly?)	+	[Cheng 12/13/2009] Unfortunately, the number of bits need to be sent by a client is no less than the binary entropy of the symbol distribution (following Shannon's theorem). Adler and Maggs' protocol assumes that the server knows the symbol distribution, and shows how the server can help the client (who doesn't know the distribution) to efficiently transmit the data. Their protocol does not lead to fewer number of bits transmitted by the client, compared to the common scenario where the client knows the symbol distribution. Therefore, this protocol (as well as several other extensions based on it) does not reduce the upstream bandwidth requirement. On the other hand, while Gagie's protocol does not rely on the assumption that the server has the symbol distribution, it does not result in better performance (in terms of number of bits sent by clients), when there is a single client/sender in the data transmission. That is, it has to leverage on correlations among data sent by multiple clients to achieve better compression ratio. In summary, existing protocols are only applicable in very few scenarios/applications. I believe the only practically useful scenario is solving bandwidth asymmetry in P2P networks. And even in that application, it's not clear whether it's worth to deploy servers to help peers utilize their upstream bandwidths. (Why not using the resources to send the content directly?)

@@ Line 1: / Line 1: @@
 == Energy-Aware DVD Playback on Laptop Computers ==
 Consider a user is watch a recorded video program using a laptop in an environment where external power is not available, e.g., in a long-distance flight. Given that the laptop is battery-powered, it may provide watch times shorter than the video programs, such as a two-hour movie. It will be frustrating if the user figures out that he/she cannot watch the complete movie only at the time the battery dies. Current technology to address this issue is quite limited: often a battery level indicator is provided by operating systems, which is often inaccurate. More importantly, it reveals no information about whether the residue energy is enough to playout the rest of the movie or not. Furthermore, even if it can provide such information, and unfortunately the energy residue is to low to complete the video program, the user cannot watch the video program. Therefore, we believe there is a need for an energy-aware video player, which enables users to watch the complete video program at the highest video quality the current battery level can support.
 == Transport Protocol for Asymmetric Communication ==
 Communication channels with asymmetric uplink/downlink bandwidths are very common nowadays. Popular residential access technologies, such as Digital Subscriber Line (DSL), often divide available bandwidth in an asymmetric manner, where the downlink bandwidth is much higher. Other systems may employ two uni-directional communication channels, where the downlink channel has much higher bandwidth. For example, in rural area, network systems may employ satellites or TV-broadcasts for downlink traffic and use analog modems for uplink traffic. While this asymmetry is arguably desirable in server-client applications, it is not ideal for peer-to-peer applications. This is because a ''client'' may exhaust it uplink bandwidth without utilizing its downlink bandwidth, which gets simply wasted.

← Older revision		Revision as of 05:09, 5 March 2009
Line 1:		Line 1:
−	~~== Some UMLs ==~~
−
−	~~<uml density="100">~~
−	~~Class.A("Point")~~
−	~~("+x: int",~~
−	~~"+y: int") ();~~
−
−	~~Class.B("Circle")~~
−	~~("radiusaaa: int")~~
−	~~("+getRadius(): int",~~
−	~~"+setRadius(r: int):void");~~
−
−	~~topToBottom(45)(A, B);~~
−
−	~~drawObjects(A, B);~~
−
−	~~clink(aggregationUni)(A, B)~~
−	~~</uml>~~
−

	== Energy-Aware DVD Playback on Laptop Computers ==		== Energy-Aware DVD Playback on Laptop Computers ==

@@ Line 1: / Line 1: @@
 == Some UMLs ==
-<uml density="200">
+<uml density="100">
 Class.A("Point")
         ("+x: int",
@@ Line 7: / Line 7: @@
 Class.B("Circle")
-        ("radius: int")
+        ("radiusaaa: int")
         ("+getRadius(): int",
          "+setRadius(r: int):void");

← Older revision		Revision as of 04:54, 5 March 2009
Line 1:		Line 1:
		+	== Some UMLs ==
		+
		+	<uml density="200">
		+	Class.A("Point")
		+	("+x: int",
		+	"+y: int") ();
		+
		+	Class.B("Circle")
		+	("radius: int")
		+	("+getRadius(): int",
		+	"+setRadius(r: int):void");
		+
		+	topToBottom(45)(A, B);
		+
		+	drawObjects(A, B);
		+
		+	clink(aggregationUni)(A, B)
		+	</uml>
		+
		+
	== Energy-Aware DVD Playback on Laptop Computers ==		== Energy-Aware DVD Playback on Laptop Computers ==
	Consider a user is watch a recorded video program using a laptop in an environment where external power is not available, e.g., in a long-distance flight. Given that the laptop is battery-powered, it may provide watch times shorter than the video programs, such as a two-hour movie. It will be frustrating if the user figures out that he/she cannot watch the complete movie only at the time the battery dies. Current technology to address this issue is quite limited: often a battery level indicator is provided by operating systems, which is often inaccurate. More importantly, it reveals no information about whether the residue energy is enough to playout the rest of the movie or not. Furthermore, even if it can provide such information, and unfortunately the energy residue is to low to complete the video program, the user cannot watch the video program. Therefore, we believe there is a need for an energy-aware video player, which enables users to watch the complete video program at the highest video quality the current battery level can support.		Consider a user is watch a recorded video program using a laptop in an environment where external power is not available, e.g., in a long-distance flight. Given that the laptop is battery-powered, it may provide watch times shorter than the video programs, such as a two-hour movie. It will be frustrating if the user figures out that he/she cannot watch the complete movie only at the time the battery dies. Current technology to address this issue is quite limited: often a battery level indicator is provided by operating systems, which is often inaccurate. More importantly, it reveals no information about whether the residue energy is enough to playout the rest of the movie or not. Furthermore, even if it can provide such information, and unfortunately the energy residue is to low to complete the video program, the user cannot watch the video program. Therefore, we believe there is a need for an energy-aware video player, which enables users to watch the complete video program at the highest video quality the current battery level can support.

← Older revision		Revision as of 19:59, 21 November 2008
Line 1:		Line 1:
		+	== Energy-Aware DVD Playback on Laptop Computers ==
		+	Consider a user is watch a recorded video program using a laptop in an environment where external power is not available, e.g., in a long-distance flight. Given that the laptop is battery-powered, it may provide watch times shorter than the video programs, such as a two-hour movie. It will be frustrating if the user figures out that he/she cannot watch the complete movie only at the time the battery dies. Current technology to address this issue is quite limited: often a battery level indicator is provided by operating systems, which is often inaccurate. More importantly, it reveals no information about whether the residue energy is enough to playout the rest of the movie or not. Furthermore, even if it can provide such information, and unfortunately the energy residue is to low to complete the video program, the user cannot watch the video program. Therefore, we believe there is a need for an energy-aware video player, which enables users to watch the complete video program at the highest video quality the current battery level can support.
		+
	== Transport Protocol for Asymmetric Communication ==		== Transport Protocol for Asymmetric Communication ==
	Communication channels with asymmetric uplink/downlink bandwidths are very common nowadays. Popular residential access technologies, such as Digital Subscriber Line (DSL), often divide available bandwidth in an asymmetric manner, where the downlink bandwidth is much higher. Other systems may employ two uni-directional communication channels, where the downlink channel has much higher bandwidth. For example, in rural area, network systems may employ satellites or TV-broadcasts for downlink traffic and use analog modems for uplink traffic. While this asymmetry is arguably desirable in server-client applications, it is not ideal for peer-to-peer applications. This is because a ''client'' may exhaust it uplink bandwidth without utilizing its downlink bandwidth, which gets simply wasted.		Communication channels with asymmetric uplink/downlink bandwidths are very common nowadays. Popular residential access technologies, such as Digital Subscriber Line (DSL), often divide available bandwidth in an asymmetric manner, where the downlink bandwidth is much higher. Other systems may employ two uni-directional communication channels, where the downlink channel has much higher bandwidth. For example, in rural area, network systems may employ satellites or TV-broadcasts for downlink traffic and use analog modems for uplink traffic. While this asymmetry is arguably desirable in server-client applications, it is not ideal for peer-to-peer applications. This is because a ''client'' may exhaust it uplink bandwidth without utilizing its downlink bandwidth, which gets simply wasted.

← Older revision		Revision as of 16:42, 6 August 2008
Line 5:		Line 5:

	To our best knowledge, there has been no practical protocol in the literature, which supports dynamic bandwidth reallocation. Using such a protocol can increase the bandwidth utilization of the residential (last-mile) links. It is even more useful in rural area, such as deserts, where uplink bandwidth is limited by the infrastructure and likely to be extremely low. Hence, designing and implementing a transport protocol for asymmetric communication, ideally a TCP drop-in, has potential to benefit a large number of Internet users all over the world.		To our best knowledge, there has been no practical protocol in the literature, which supports dynamic bandwidth reallocation. Using such a protocol can increase the bandwidth utilization of the residential (last-mile) links. It is even more useful in rural area, such as deserts, where uplink bandwidth is limited by the infrastructure and likely to be extremely low. Hence, designing and implementing a transport protocol for asymmetric communication, ideally a TCP drop-in, has potential to benefit a large number of Internet users all over the world.
−
−	~~abcd~~

@@ Line 2: / Line 2: @@
 Communication channels with asymmetric uplink/downlink bandwidths are very common nowadays. Popular residential access technologies, such as Digital Subscriber Line (DSL), often divide available bandwidth in an asymmetric manner, where the downlink bandwidth is much higher. Other systems may employ two uni-directional communication channels, where the downlink channel has much higher bandwidth. For example, in rural area, network systems may employ satellites or TV-broadcasts for downlink traffic and use analog modems for uplink traffic. While this asymmetry is arguably desirable in server-client applications, it is not ideal for peer-to-peer applications. This is because a ''client'' may exhaust it uplink bandwidth without utilizing its downlink bandwidth, which gets simply wasted.
-One nature question is: Can we allocate the, otherwise idling, downlink bandwidth for uplink usage, so that the uplink bandwidth is increased? In 2001, from information theory aspect, Adler and Maggs [[media:AM01.pdf]] showed that using a properly-designed protocol, the downlink bandwidth can be used to accelerate the upload speed. Notice that, they did not propose an actual ''network'' protocol that can be used in the wild. Instead, they strived to ''prove'' the feasibility of dynamically reallocating bandwidths. Extended works in the literature have also reveal the upper bound of the potential improvement on upstream bandwidth. See [[media:Gagie06.pdf]] for a brief survey and references.
+One nature question is: Can we allocate the, otherwise idling, downlink bandwidth for uplink usage, so that the uplink bandwidth is increased? In 2001, from information theory aspect, Adler and Maggs [[media:AM01.pdf]] showed that using a properly-designed protocol, the downlink bandwidth can be used to accelerate the upload speed. Notice that, they did not propose an actual ''network'' protocol that can be used in the wild. Instead, they strived to ''prove'' the feasibility of dynamically reallocating bandwidths. Other works in the literature have also reveal the upper bound of the potential improvement on upstream bandwidth. See [[media:Gagie06.pdf]] for a brief survey and references.
-To our best knowledge, there has been no practical protocol in the literature, which supports dynamic bandwidth reallocation. Using such a protocol can increase the bandwidth utilization of the residential (last-mile) links. It is even more useful in rural area, such as deserts, where uplink bandwidth is limited by the infrastructure and likely to be low. Hence, designing and implementing a transport protocol for asymmetric communication, ideally a TCP drop-in, has potential to benefit a large number of users all over the world.
+To our best knowledge, there has been no practical protocol in the literature, which supports dynamic bandwidth reallocation. Using such a protocol can increase the bandwidth utilization of the residential (last-mile) links. It is even more useful in rural area, such as deserts, where uplink bandwidth is limited by the infrastructure and likely to be extremely low. Hence, designing and implementing a transport protocol for asymmetric communication, ideally a TCP drop-in, has potential to benefit a large number of Internet users all over the world.