<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>eCommons Collection: Computing and Information Science Technical Reports</title>
    <link>http://hdl.handle.net/1813/5602</link>
    <description />
    <items>
      <rdf:Seq>
        <rdf:li resource="http://hdl.handle.net/1813/11220" />
        <rdf:li resource="http://hdl.handle.net/1813/11153" />
        <rdf:li resource="http://hdl.handle.net/1813/11102" />
        <rdf:li resource="http://hdl.handle.net/1813/11101" />
      </rdf:Seq>
    </items>
  </channel>
  <image>
    <title>The Channel Image</title>
    <url>http://dspace.library.cornell.edu/retrieve/32119</url>
    <link>http://hdl.handle.net/1813/5602</link>
  </image>
  <textInput>
    <title>The Collection's search engine</title>
    <description>Search the Channel</description>
    <name>search</name>
    <link>http://dspace.library.cornell.edu/simple-search</link>
  </textInput>
  <item rdf:about="http://hdl.handle.net/1813/11220">
    <title>On The Difficulty of Finding the Nearest Peer in P2P Systems</title>
    <link>http://hdl.handle.net/1813/11220</link>
    <description>Title: On The Difficulty of Finding the Nearest Peer in P2P Systems
&lt;br/&gt;
&lt;br/&gt;Authors: Vishnumurthy, Vivek; Francis, Paul
&lt;br/&gt;
&lt;br/&gt;Abstract: Finding the nearest peer, in terms of latency, is an important problem in many Internet applications. In this paper, we argue that solutions that only examine inter-peer latencies as part of their operation will find it infeasible, in certain cases, to discover the nearest peer in P2P systems. The difficulty arises out of the way the last hop is typically laid out in the Internet, where a single PoP (point of presence) belonging to an ISP provides connectivity to numerous client networks. This setup leads to a large number of peers being at about the same latency from one another, which, we argue, presents a serious obstacle when a peer tries to discover another peer residing in the same network as itself. We use large-scale measurements over hosts in the Azureus P2P network and DNS servers to show that this condition does occur in real settings, and use simulations of the Meridian closest-server algorithm to show that the condition does indeed lead to difficulty in finding the exact-closest peer. We also propose a few heuristics that help address this issue.</description>
  </item>
  <item rdf:about="http://hdl.handle.net/1813/11153">
    <title>Hyperproperties: Verification of Proofs</title>
    <link>http://hdl.handle.net/1813/11153</link>
    <description>Title: Hyperproperties: Verification of Proofs
&lt;br/&gt;
&lt;br/&gt;Authors: Bueno, Denis L.; Clarkson, Michael R.
&lt;br/&gt;
&lt;br/&gt;Abstract: This paper formalizes some proofs by Clarkson and Schneider about&#xD;
hyperproperties. The proofs are mechanically verified using the proof&#xD;
assistant Isabelle.</description>
  </item>
  <item rdf:about="http://hdl.handle.net/1813/11102">
    <title>A Dirty-Slate Approach to Routing Scalability</title>
    <link>http://hdl.handle.net/1813/11102</link>
    <description>Title: A Dirty-Slate Approach to Routing Scalability
&lt;br/&gt;
&lt;br/&gt;Authors: Ballani, Hitesh; Francis, Paul; Wang, Jia; Cao, Tuan
&lt;br/&gt;
&lt;br/&gt;Abstract: This paper presents Virtual Aggregation, an&#xD;
architecture that attempts to tackle the Internet routing scalability&#xD;
problem. Our approach does not require any changes&#xD;
to router software and routing protocols and can be deployed&#xD;
by any ISP without the cooperation of other ISPs. Hence,&#xD;
Virtual Aggregation is a configuration-only solution. The key&#xD;
insight here is to use divide-and-conquer so that default-free&#xD;
zone routers don?t need to maintain the entire routing table.&#xD;
Instead, an ISP can modify its internal routing such that&#xD;
individual routers in its network only maintain a part of the&#xD;
routing table.&#xD;
We evaluate the application of Virtual Aggregation to a&#xD;
few tier-1 and tier-2 ISPs and show that it can reduce routing&#xD;
table size on individual routers by an order of magnitude&#xD;
while imposing almost no traffic stretch and very little increase&#xD;
in router load. We also deploy Virtual Aggregation across&#xD;
two different testbeds comprising of Cisco and Linux routers.&#xD;
Finally, we detail some shortcomings of the proposed design&#xD;
and discuss alternative designs that alleviate some of these.&#xD;
However, in spite of the limitations, we believe that the&#xD;
simplicity of the proposal and its possible short-term impact&#xD;
on routing scalability suggest that it is an alternative worth&#xD;
considering.</description>
  </item>
  <item rdf:about="http://hdl.handle.net/1813/11101">
    <title>ShutUp: End-to-End Containment of Unwanted Traffic</title>
    <link>http://hdl.handle.net/1813/11101</link>
    <description>Title: ShutUp: End-to-End Containment of Unwanted Traffic
&lt;br/&gt;
&lt;br/&gt;Authors: Guha, Saikat; Taft, Nina
&lt;br/&gt;
&lt;br/&gt;Abstract: While the majority of Denial-of-Service (DoS) defense proposals&#xD;
assume a purely infrastructure-based architecture, some recent&#xD;
proposals suggest that the attacking endhost may be enlisted&#xD;
as part of the solution, through tamper-proof software,&#xD;
network-imposed incentives, or user altruism. While intriguing,&#xD;
these proposals ultimately raise the deployment bar by requiring&#xD;
both the infrastructure and endhosts to cooperate. In this&#xD;
paper, we explore the design of a pure end-to-end architecture&#xD;
based on tamper-proof endhost software implemented for instance&#xD;
with trusted platforms and virtual machines. We present&#xD;
the design of a ?Shutup Service?, whereby the recipient of unwanted&#xD;
traffic can ask the sender to slowdown or stop. We show&#xD;
that this service is effective in stopping DoS attacks, and in significantly&#xD;
slowing down other types of unwanted traffic such as&#xD;
worms. The Shutup service is incrementally deployable with&#xD;
buy-in from OS or antivirus vendors, requiring only minimal&#xD;
changes to the endhost software stack and no changes to the protocol&#xD;
stack. We show through experimentation that the service&#xD;
is effective and has little impact on legitimate traffic.</description>
  </item>
</rdf:RDF>

