<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Why the &#8220;stupid network&#8221; isn&#8217;t our destiny after all</title>
	<atom:link href="http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/feed/" rel="self" type="application/rss+xml" />
	<link>http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/</link>
	<description></description>
	<lastBuildDate>Fri, 24 May 2013 09:22:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Alex Benik</title>
		<link>http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/#comment-1272600</link>
		<dc:creator><![CDATA[Alex Benik]]></dc:creator>
		<pubDate>Fri, 21 Dec 2012 16:30:13 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=594464#comment-1272600</guid>
		<description><![CDATA[Joe,
Nice article.  The Stupid Network and its spiritual predecessor  the End-to-Eng argument should be required reading for anyone in communications.  However, I think of them more as architectural maxims more than implementation guidelines.   In practice many devices break both, firewalls, NATs, SBC, proxies, etc.]]></description>
		<content:encoded><![CDATA[<p>Joe,<br />
Nice article.  The Stupid Network and its spiritual predecessor  the End-to-Eng argument should be required reading for anyone in communications.  However, I think of them more as architectural maxims more than implementation guidelines.   In practice many devices break both, firewalls, NATs, SBC, proxies, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joeweinman</title>
		<link>http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/#comment-1263674</link>
		<dc:creator><![CDATA[joeweinman]]></dc:creator>
		<pubDate>Mon, 17 Dec 2012 17:46:10 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=594464#comment-1263674</guid>
		<description><![CDATA[Hi Adi...not sure that distributing that much information to each of billions of endpoints is as efficient as doing it in the network. Moreover, independent decisions may not lead to an optimal global decision.  For example, each endpoint might simultaneously select the same least congested path, leading to poor throughput and suboptimal transport resource allocation. Peer to peer coordination or mechanisms such as exponential backoff have their own issues.  The basic point is that many functions are best performed by the endpoint, locally, but some functions may be best performed &quot;in the network&quot;: globally, regionally, at the provider edge, etc.]]></description>
		<content:encoded><![CDATA[<p>Hi Adi&#8230;not sure that distributing that much information to each of billions of endpoints is as efficient as doing it in the network. Moreover, independent decisions may not lead to an optimal global decision.  For example, each endpoint might simultaneously select the same least congested path, leading to poor throughput and suboptimal transport resource allocation. Peer to peer coordination or mechanisms such as exponential backoff have their own issues.  The basic point is that many functions are best performed by the endpoint, locally, but some functions may be best performed &#8220;in the network&#8221;: globally, regionally, at the provider edge, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ramaswamy (Adi) Aditya</title>
		<link>http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/#comment-1260769</link>
		<dc:creator><![CDATA[Ramaswamy (Adi) Aditya]]></dc:creator>
		<pubDate>Sun, 16 Dec 2012 17:24:26 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=594464#comment-1260769</guid>
		<description><![CDATA[Using a routing protocol which has insufficient information about constraints (end-host capacity, segment used capacity or latency) is currently how packets get from one end of the network to another. You are suggesting that the Stanford approach is saying the routing protcols should be updated or augmented by others to do that. Perhaps that is just a waypoint to a place where the endpoints are given all the possible paths with all known constraints and have the endpoint select the route? (Traffic engineering by the end point(s)) That is of course very scary to a network operator who doesn&#039;t want the endpoint to make such decisions, but we already encourage them to do it using DNS SRV records or other similar application level mechanisms which are much more resilient in the face of network problems/misconfiguration than network-mediated ones like load-balancers.

Yes, we now have a better way to disseminate further attributes about network conditions using SDN, but that doesn&#039;t mean the network is getting more information to make decisions for the right reasons; it is doing so to allow network operators more control at a cost low enough that Isenberg&#039;s suggestion can be set aside -- the last time it was embraced because it allowed network operators to not spend as much (although that has turned out to be the right thing to do in hindsight for entirely different reasons -- end-to-end principle etc.)]]></description>
		<content:encoded><![CDATA[<p>Using a routing protocol which has insufficient information about constraints (end-host capacity, segment used capacity or latency) is currently how packets get from one end of the network to another. You are suggesting that the Stanford approach is saying the routing protcols should be updated or augmented by others to do that. Perhaps that is just a waypoint to a place where the endpoints are given all the possible paths with all known constraints and have the endpoint select the route? (Traffic engineering by the end point(s)) That is of course very scary to a network operator who doesn&#8217;t want the endpoint to make such decisions, but we already encourage them to do it using DNS SRV records or other similar application level mechanisms which are much more resilient in the face of network problems/misconfiguration than network-mediated ones like load-balancers.</p>
<p>Yes, we now have a better way to disseminate further attributes about network conditions using SDN, but that doesn&#8217;t mean the network is getting more information to make decisions for the right reasons; it is doing so to allow network operators more control at a cost low enough that Isenberg&#8217;s suggestion can be set aside &#8212; the last time it was embraced because it allowed network operators to not spend as much (although that has turned out to be the right thing to do in hindsight for entirely different reasons &#8212; end-to-end principle etc.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joeweinman</title>
		<link>http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/#comment-1260645</link>
		<dc:creator><![CDATA[joeweinman]]></dc:creator>
		<pubDate>Sun, 16 Dec 2012 16:31:30 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=594464#comment-1260645</guid>
		<description><![CDATA[Hi Michael...I did read the paper.  It is an important paper, a seminal paper, and I agree remains largely true and relevant, and is likely to remain so.  For example, an open innovation ecosystem that empowers millions of endpoint and application development entities (individuals and firms) via market-based mechanisms surely trumps centralized, monolithic planning.  A standard, flexible network platform (IP/Internet), accelerates this innovation, as Stanford&#039;s Barbara van Schewick argues in Internet Architecture and Innovation.

However, Isenberg argued for &quot;nothing but dumb transport in the middle,&quot; &quot;just deliver the bits, stupid,&quot; and &quot;no fancy network routing.&quot; I think that the Stanford example helps illustrate that endpoints alone can&#039;t always determine a global optimum in a distributed computing environment.  Emerging technologies can help achieve such optima.]]></description>
		<content:encoded><![CDATA[<p>Hi Michael&#8230;I did read the paper.  It is an important paper, a seminal paper, and I agree remains largely true and relevant, and is likely to remain so.  For example, an open innovation ecosystem that empowers millions of endpoint and application development entities (individuals and firms) via market-based mechanisms surely trumps centralized, monolithic planning.  A standard, flexible network platform (IP/Internet), accelerates this innovation, as Stanford&#8217;s Barbara van Schewick argues in Internet Architecture and Innovation.</p>
<p>However, Isenberg argued for &#8220;nothing but dumb transport in the middle,&#8221; &#8220;just deliver the bits, stupid,&#8221; and &#8220;no fancy network routing.&#8221; I think that the Stanford example helps illustrate that endpoints alone can&#8217;t always determine a global optimum in a distributed computing environment.  Emerging technologies can help achieve such optima.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: michael</title>
		<link>http://gigaom.com/2012/12/15/why-the-stupid-network-isnt-our-destiny-after-all/#comment-1259412</link>
		<dc:creator><![CDATA[michael]]></dc:creator>
		<pubDate>Sun, 16 Dec 2012 06:34:26 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=594464#comment-1259412</guid>
		<description><![CDATA[The author either didn&#039;t read or didn&#039;t understand David Isenberg paper. David put a very different meaning into network intelligence.

And the paper is still super relevant - Just ask any mobile operator what is their main challenge...]]></description>
		<content:encoded><![CDATA[<p>The author either didn&#8217;t read or didn&#8217;t understand David Isenberg paper. David put a very different meaning into network intelligence.</p>
<p>And the paper is still super relevant &#8211; Just ask any mobile operator what is their main challenge&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
