<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>SMARTech Collection: School of Computer Science Technical Reports</title>
    <link>http://smartech.gatech.edu/handle/1853/14330</link>
    <description>The School of Computer Science pushes the boundaries in education and research to design, build and understand the complex systems that are central to society.</description>
    <textInput>
      <title>The Collection's search engine</title>
      <description>Search the Channel</description>
      <name>search</name>
      <link>http://smartech.gatech.edu/simple-search</link>
    </textInput>
    <item>
      <title>Life (and routing) on the Wireless Manifold</title>
      <link>http://smartech.gatech.edu/handle/1853/19894</link>
      <description>Title: Life (and routing) on the Wireless Manifold
&lt;br/&gt;
&lt;br/&gt;Authors: Kanade, Varun; Vempala, Santosh
&lt;br/&gt;
&lt;br/&gt;Abstract: We present the wireless manifold, a 2-dimensional surface in 3-dimensional space with the property that geodesic&#xD;
distances accurately capture wireless signal strengths.&#xD;
A compact representation of the manifold can be reconstructed from a sparse set of signal measurements.&#xD;
The manifold distance suggests a simple routing algorithm that avoids obstacles, naturally handles mobile&#xD;
nodes without explicitly maintaining the connectivity&#xD;
graph and is more efficient compared to using Euclidean&#xD;
distance as measured by success rate, routing load and&#xD;
failure tolerance. Placing sensors to cover the manifold&#xD;
is more effective than covering the underlying physical&#xD;
space.</description>
      <pubDate>Sun, 29 Oct 2006 22:58:59 GMT</pubDate>
    </item>
    <item>
      <title>Building a Better Mousetrap</title>
      <link>http://smartech.gatech.edu/handle/1853/14350</link>
      <description>Title: Building a Better Mousetrap
&lt;br/&gt;
&lt;br/&gt;Authors: Ramachandran, Anirudh; Seetharaman, Srinivasan; Feamster, Nick; Vazirani, Vijay
&lt;br/&gt;
&lt;br/&gt;Abstract: Routers in the network core are unable to maintain detailed&#xD;
statistics for every packet; thus, traffic statistics are often&#xD;
based on packet sampling, which reduces accuracy. Because&#xD;
tracking large ("heavy-hitter") traffic flows is important both&#xD;
for pricing and for traffic engineering, much attention has&#xD;
focused on maintaining accurate statistics for such flows, often&#xD;
at the expense of small-volume flows. Eradicating these&#xD;
smaller flows makes it difficult to observe communication&#xD;
structure, which is sometimes more important than maintaining&#xD;
statistics about flow sizes.&#xD;
This paper presents FlexSample, a sampling framework&#xD;
that allows network operators to get the best of both worlds:&#xD;
For a fixed sampling budget, FlexSample can capture significantly&#xD;
more small-volume flows for only a small increase in&#xD;
relative error of large traffic flows. FlexSample uses a fast,&#xD;
lightweight counter array that provides a coarse estimate of&#xD;
the size ("class") of each traffic flow; a router then can sample&#xD;
at different rates according to the class of the traffic using&#xD;
any existing sampling strategy. Given a fixed sampling rate&#xD;
and a target fraction of sampled packets to allocate across&#xD;
traffic classes, FlexSample computes packet sampling rates&#xD;
for each class that achieve these allocations online. Through&#xD;
analysis and trace-based experiments, we find that FlexSample&#xD;
captures at least 50% more mouse flows than strategies&#xD;
that do not perform class-dependent packet sampling. We&#xD;
also show how FlexSample can be used to capture unique&#xD;
flows for specific applications.</description>
      <pubDate>Sun, 29 Oct 2006 22:58:59 GMT</pubDate>
    </item>
    <item>
      <title>Overlay Network Assignment in PlanetLab With NetFinder</title>
      <link>http://smartech.gatech.edu/handle/1853/14349</link>
      <description>Title: Overlay Network Assignment in PlanetLab With NetFinder
&lt;br/&gt;
&lt;br/&gt;Authors: Zhu, Yong; Ammar, Mostafa H. (Mostafa Hamed)
&lt;br/&gt;
&lt;br/&gt;Abstract: PlanetLab has been widely used in the networking&#xD;
community to test and deploy user-defined overlays. Serving as&#xD;
a meta testbed to support multiple overlay networks, PlanetLab&#xD;
has significantly lowered the barriers to build new overlays.&#xD;
However, PlanetLab users always face the problem of selecting&#xD;
a set of nodes and interconnecting them to form the desired&#xD;
overlay network. Unfortunately, such a task is usually carried out&#xD;
manually by individual users and sometimes in an ad-hoc manner.&#xD;
In this paper, we develop NetFinder, an automatic overlay network&#xD;
configuration tool to efficiently allocate PlanetLab resources&#xD;
to individual overlays. NetFinder continuously monitors the resource&#xD;
utilization of PlanetLab and accepts a user-defined overlay&#xD;
topology as input and selects the set of PlanetLab nodes and&#xD;
their interconnection for the user overlay. Experimental results&#xD;
indicate that overlay networks constructed by NetFinder have&#xD;
more stable and significantly higher bandwidth than alternative&#xD;
schemes and near optimal available CPU.</description>
      <pubDate>Sat, 29 Oct 2005 22:58:59 GMT</pubDate>
    </item>
    <item>
      <title>How to Lease the Internet in Your Spare Time</title>
      <link>http://smartech.gatech.edu/handle/1853/14348</link>
      <description>Title: How to Lease the Internet in Your Spare Time
&lt;br/&gt;
&lt;br/&gt;Authors: Feamster, Nick; Gao, Lixin; Rexford, Jennifer
&lt;br/&gt;
&lt;br/&gt;Abstract: Today's Internet Service Providers (ISPs) serve two roles:&#xD;
managing their network infrastructure and providing (arguably&#xD;
limited) services to end users. We argue that coupling&#xD;
these roles impedes the deployment of new protocols&#xD;
and architectures. Instead, the future Internet should support&#xD;
two separate entities: infrastructure providers (who manage&#xD;
the physical infrastructure) and service providers (who deploy&#xD;
network protocols and offer end-to-end services). We&#xD;
present a high-level design for Cabo, an architecture that enables&#xD;
this separation, and we describe challenges associated&#xD;
with realizing this architecture.</description>
      <pubDate>Sat, 29 Oct 2005 22:58:59 GMT</pubDate>
    </item>
  </channel>
</rss>

