<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Dave Siegel</title><link>http://disqus.com/people/839b98ffc264da724bdebf4354ed876d/</link><description></description><language>en</language><lastBuildDate>Fri, 21 Sep 2007 19:21:56 -0000</lastBuildDate><item><title>Re: Is Google the new Global Crossing&amp;#63;</title><link>http://mathewingram.disqus.com/is_google_the_new_global_crossing63/#comment-1315982</link><description>Google seems to be suffering from a bit of identity crisis, don't they.  :-)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Siegel</dc:creator><pubDate>Fri, 21 Sep 2007 19:21:56 -0000</pubDate></item><item><title>Re: Tiered peering and business models</title><link>http://bennettblog.disqus.com/tiered_peering_and_business_models/#comment-2134184</link><description>No, he's right.  &lt;br&gt;&lt;br&gt;The carriers that have been most vocal against net neutrality would rather have the big content providers connect directly to them, paying for a connection to their network, then they would go through the effort of implementing a QoS capability across their network boundaries to their peers.  The reason is that it's simpler and follows conventional business models.&lt;br&gt;&lt;br&gt;Remember, at the end of the day the primary motivation is for the carrier to make more money.  Some of this desire is basic business sense, some of it is around concern for continued price erosion, and some of it is pure greed.&lt;br&gt;&lt;br&gt;An evolution to an Internet with QoS does not necessarily satisfy these motivations.  Don't get me wrong, there are still reasons to consider it, but I personally came to the conclusion some time ago that the addition of QoS capability does not, in and of itself, change the economics of the Internet.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Siegel</dc:creator><pubDate>Thu, 22 Jun 2006 20:10:00 -0000</pubDate></item><item><title>Re: Shaw&amp;#8217;s Quality of Service Enhancement</title><link>http://bennettblog.disqus.com/shaw8217s_quality_of_service_enhancement/#comment-2134309</link><description>I applaud Shaw cable for creating a service offering that gives their voice/voip competitors the ability to have a properly performing service on their network.  I'm not exactly sure how they do it efficiently, since identifying the packets from all those third party providers might be a man-power intenstive activity.&lt;br&gt;&lt;br&gt;I can only imagine that there must be more competition in the broadband market in that particular area of Canada, and they have found a way that they can differentiate their broadband service from their competitors.  They will have to differentiate their VoIP service from third party VoIP carriers as well; it will have to compete on its own merits.  This is a good thing as well.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Siegel</dc:creator><pubDate>Thu, 22 Jun 2006 20:22:25 -0000</pubDate></item><item><title>Re: Shaw&amp;#8217;s Quality of Service Enhancement</title><link>http://bennettblog.disqus.com/shaw8217s_quality_of_service_enhancement/#comment-2134310</link><description>Sorry Max, but RSVP has nothing to do with QoS.  You're thinking of MPLS, not QoS.&lt;br&gt;&lt;br&gt;Interprovider QoS is possible to do today with relatively trivial translation tables applied to the network borders between carriers.  Assuming that all major carriers supported QoS on the equipment that runs their Internet service (some of the older routers or linecards require upgrades), it would be a simple matter of turning it on from a technical perspective.  There are no scaling concerns because there are no signalling aspects.  The routers simply place packets into a queue based on the ToS bit value in the IP header.&lt;br&gt;&lt;br&gt;It's not enabled today because there is no business reason to turn it on.  If more broadband companies go the route of Shaw Cable, that situation might change though.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Siegel</dc:creator><pubDate>Thu, 22 Jun 2006 20:29:26 -0000</pubDate></item><item><title>Re: Cringely on the Neutrality fiction</title><link>http://bennettblog.disqus.com/cringely_on_the_neutrality_fiction/#comment-2134286</link><description>I've been thinking a bit about IPTV and its QoS requirements lately.&lt;br&gt;&lt;br&gt;In a differentiated services model of QoS where traffic is place into classes, you can find three general ways to classify the needs of applications:&lt;br&gt;&lt;br&gt;EF: latency, loss, and jitter sensitive&lt;br&gt;AF: latency and loss sensitive, but not jitter sensitive&lt;br&gt;BE: loss sensitive, but not latency or jitter sensitive&lt;br&gt;&lt;br&gt;VoIP is definitely EF.  Most Internet applications are BE.  We're all very familiar with this.  IP Video conferencing is also EF.  But IPTV, while extremely loss sensitive, is not especially jitter or latency sensitive.  This suggests that maybe it doesn't deserve to sit at the same level as VoIP, but maybe lower in the tree.&lt;br&gt;&lt;br&gt;Because of it's loss sensitivity, it either needs to have quality management built in at the application layer so that it shuts off channels if bandwidth isn't available, or the network needs to have admission control capabilities more so than the ability to prioritize, otherwise IPTV is going to kill the whole pipe as well as itself when it overdrives the broadband connection.&lt;br&gt;&lt;br&gt;I'm not sure anyone's even been thinking about it from that perspective.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Siegel</dc:creator><pubDate>Thu, 22 Jun 2006 20:35:58 -0000</pubDate></item><item><title>Re: Cringely on the Neutrality fiction</title><link>http://bennettblog.disqus.com/cringely_on_the_neutrality_fiction/#comment-2134292</link><description>Richard says:&lt;br&gt;&lt;br&gt;&lt;blockquote&gt;&lt;br&gt;For all forms of live video, Jitter is actually more sensitive than you might think because of the synchronization issues between the audio and video tracks and the fact that deep de-jittering buffers get in the way of fast channel surfing. The specs are actually very, very tight.&lt;br&gt;&lt;/blockquote&gt;&lt;br&gt;&lt;br&gt;Then maybe they need to consider changing the protocol/encoding so that the voice is encoded with the video. Its a shame when a poorly architected design puts excessive demands on the network infrastructure when it could have been avoided.&lt;br&gt;&lt;br&gt;&lt;blockquote&gt;The Internet needs some enhancements to handle video, in the form of a reliable multicast protocol (with local retransmits),&lt;br&gt;&lt;/blockquote&gt;&lt;br&gt;&lt;br&gt;It is not the job of multicast, a layer 3 protocol, to handle things like error checking, sequencing, and retransmitsthat belongs in layer 4, similar to what TCP does for IP Unicast.&lt;br&gt;&lt;br&gt;Dont you agree?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Siegel</dc:creator><pubDate>Fri, 23 Jun 2006 15:33:09 -0000</pubDate></item></channel></rss>