<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Network on bramp.net</title>
    <link>https://blog.bramp.net/</link>
    <description>Recent content in Network on bramp.net</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-GB</language>
    <lastBuildDate>Tue, 09 Feb 2010 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.bramp.net/tags/network/" rel="self" type="application/rss+xml" />
    
    <item>
      <title>Facilitating Network Auto Configuration In Next Generation Internet Protocols</title>
      <link>https://blog.bramp.net/publication/facilitating-network-auto-configuration-in-next-generation-internet-protocols/</link>
      <pubDate>Tue, 09 Feb 2010 00:00:00 +0000</pubDate>
      
      <guid>https://blog.bramp.net/publication/facilitating-network-auto-configuration-in-next-generation-internet-protocols/</guid>
      <description><p>Matthew Jakeman, Andrew Brampton, Stephen Pink</p>
<p>In proceedings FutureNet II – Second international workshop on the network of the future in conjunction with IEEE Globecom</p>
<blockquote>
<p><strong>Abstract</strong></p>
<p>The infrastructure of the modern Internet has become a complex mesh of varying network types. A single network<br>
protocol cannot optimally support every underlying technology and the diverse nature of these networks places increasing strain on the concept of running IP over everything and everything over IP. The introduction of new protocols and services also forces network administrators to employ techniques such as tunneling to ensure end-to-end IP connectivity. Unfortunately these techniques inherently require some form of efficiency trade-off and are not<br>
an ideal long term solution.</p>
<p>To address these issues, this paper proposes a new network layer protocol, NP++, which uses a level of indirection between the logical and physical specifications of the protocol. NP++ also enables the protocol to automatically configure which physical mapping is used over a link with no direct input from the user.<br>
This allows the protocol to change its transmission characteristics depending on the type of underlying network while presenting a unified view to the upper layers. This ensures a higher level of flexibility along with the potential to increase efficiency. The implementation of the NP++ prototype is also demonstrated with a view to encouraging its use when researching next generation Internet technologies.</p>
</blockquote>
<p><a href="https://github.com/bramp/publication/raw/master/network-auto-config/GLOBECOM09/facilitating_network_auto_configuration_in_next_generation_internet_protocols.pdf">PDF Download</a></p>
</description>
    </item>
    
    <item>
      <title>Evaluating the Performance of Network Protocol Processing on Multi-core Systems</title>
      <link>https://blog.bramp.net/publication/evaluating-the-performance-of-network-protocol-processing-on-multi-core-systems/</link>
      <pubDate>Tue, 26 May 2009 00:00:00 +0000</pubDate>
      
      <guid>https://blog.bramp.net/publication/evaluating-the-performance-of-network-protocol-processing-on-multi-core-systems/</guid>
      <description><p>Matthew Faulkner and Andrew Brampton and Stephen Pink</p>
<p>In proceedings of the International Conference on Advanced Information Networking and Applications (AINA)</p>
<p><strong>This paper won the IEEE Best Paper award</strong></p>
<blockquote>
<p><strong>Abstract</strong></p>
<p>Improvements at the physical network layer have enabled technologies such as 10 Gigabit Ethernet. Single core end-systems are unable to fully utilise these networks, due to limited clock cycles. Using a Multi-core architecture is one method which increases the number of available cycles, and thus allow networks to be fully utilised. However, using these systems creates a new set of challenges for network protocol processing, for example, deciding how best to utilise many cores for high network performance. This paper examines different ways the cores of a multi-core system can be utilised, and, by experimentation, we show that in an eight core system deciding which cores to use is important. In one test, there was a 40% discrepancy in CPU utilisation depending on which cores were used. This discrepancy results from the resources each core shares, an example being the multi-hierarchy CPU caches, and to which bus the processors are connected.</p>
</blockquote>
<p><a href="https://github.com/bramp/publication/raw/master/multi-core-networking/AINA-09/aina-09.pdf">PDF Download</a></p>
</description>
    </item>
    
  </channel>
</rss>
