Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Ashwin Natarajan

dblp:40/6904 · DBLP profile ↗
← Back
4ranked-venue papers
2as first author
0since 2021 · last 2009
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 3 · 1 first-authorGraphics, computer vision, multimedia, augmented reality and games · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer networks
1 paper
Content delivery and video streaming · 50% Edge and fog computing · 50%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Distributed systems · 100%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Content delivery and video streaming › peer-to-peer streaming
peer-to-peer live streaming
0.112007
On scheduling of peer-to-peer video services · IEEE J. Sel. Areas Commun. 2007
Edge and fog computing › service provisioning
service scheduling
0.112007
On scheduling of peer-to-peer video services · IEEE J. Sel. Areas Commun. 2007
Distributed systems
peer-to-peer systems
0.012007
On scheduling of peer-to-peer video services · IEEE J. Sel. Areas Commun. 2007

Methods — techniques the papers use, named apart from their topics

shaking technique · 0.1performance study · 0.1
YearPublicationVenuePosition
2009 An enhanced client-centric approach for efficient video broadcast
Ashwin Natarajan, Ying Cai 0001, Johnny S. Wong
Multim. Tools Appl.1
2007 On scheduling of peer-to-peer video services
abstract
Peer-to-peer (P2P) video systems provide a cost-effective way for a large number of hosts to collaborate for video sharing. Two features characterize such a system: 1) a video is usually available on many participating hosts, and 2) different hosts typically have different sets of videos, though some may partially overlap. From a client's perspective, it can be served by any host having the video it requests. From a server's perspective, it be used to serve any client requesting the videos it has. Thus, an important question is, which servers should be used to serve which clients in the system? In this paper, we refer to this problem as service scheduling and show that different matches between clients and servers can result in significantly different system performance. Finding a right server for each client is challenging not only because a client can choose only the servers that are within its limited search scope, but also because clients arrive at different times, which are not known a priori. In this paper, we address these challenges with a novel technique called Shaking. While the proposed technique makes it possible for a client to be served by a server that is beyond the client's own search scope, it is able to dynamically adjust the match between the servers and their pending requests as new requests arrive. Our performance study shows that our new technique can dynamically balance the system workload and significantly improve the overall system performance
Ying Cai 0001, Ashwin Natarajan, Johnny S. Wong
IEEE J. Sel. Areas Commun.2
2005 Shaking service requests in peer-to-peer video systems
abstract
Peer-to-peer (P2P) video system is characterized by two features: 1) a video is usually available on many participating hosts, and 2) different hosts typically have different sets of videos, though some may partially overlap. From a client's perspective, it can be served by any host having the video it requests. From a server's perspective, it will be used to serve any client requesting the videos it has. In this paper, we refer to the problem of who-serves-whom as service scheduling and show that different matches between clients and servers can result in significantly different system performance. Finding a right server for each client is challenging not only because a client can choose only the servers that are within its limited search scope, but also because clients arrive at different times, which are not known a priori. To address these challenges, we propose a novel technique called shaking and our performance study shows that it can effectively boost the overall system performance.
Ying Cai 0001, Ashwin Natarajan, Johnny S. Wong
GLOBECOM2
2004 Improving server broadcast efficiency through better utilization of client receiving bandwidth
abstract
Periodic broadcast is a cost-effective solution for disseminating popular videos. This strategy has the potential to serve a very large community with minimal broadcast bandwidth: regardless of the number of video requests, the worst service latency to all clients is constant. Although many efficient schemes have been proposed, most of them impose some rigid requirement on client receiving bandwidth. They either demand clients to have the same bandwidth as the video server, or limit them to receive no more than two video streams at any one time. In our previous work, we addressed this problem by proposing a client-centric approach (CCA). Unlike any other technique, CCA takes both server broadcast bandwidth and client receiving bandwidth into design consideration. More specifically, CCA allows clients to use all their receiving capability for prefetching broadcast data. Therefore, given a fixed broadcast bandwidth, CCA can achieve shorter broadcast period with an improved client communication capability. In this paper, we present a novel technique to further leverage client bandwidth for more efficient video broadcast. We prove the correctness of this new technique and provide analytical evaluations to show that with the same client bandwidth, it achieves significantly better performance than CCA.
Ashwin Natarajan, Ying Cai 0001, Johnny S. Wong
IPCCC1