Re: [p2pi] Follow-Up from Comcast Presentation

["Robb Topolski" <robb at funchords.com>]

My feedback is that discrimination based on user-history is no better than protocol-discriminatory behavior. Just as the Internet Standards do not lead developers to expect a network that discriminates against a protocol, those same standards do not prepare developers for a network that is discriminating based on nebulous concepts of "fairness."  

In particular, I'm concerned with possible scenarios such as someone who is mid-upload of 1100 European vacation pictures (all at 8 Megapixel) when her husband has a medical emergency.  She dials 9-1-1 on Vonage or whatever non-Comcast VOIP device. Comcast delays and drops her packets as the new system places her VOIP call is behind long packet queues created by other activity in her neighborhood.  

Another set of scenarios pertains to users, applications, or devices reserving bandwidth that should be available to them within their teir, and the unexpected malfunction when the bandwidth that they purchased is not available.  First, there is the RSVP scheduler native to Microsoft OS's for many years. Second, there are applications like NetLimiter, where responsible and savvy users can segment their bandwidth or keep certain applications under control  Third, and ironically, almost all P2P applications have upload bandwidth limiters.  Users are generally advised to set these to less than their subscribed bandwidth so as to allow other Internet uses (such as VOIP calls).  Finally, there are many consumer hardware devices that allow users to tune prioritization.  For example, many consumer gateway-router devices marketed under different brands use a QoS engine by Ubicom.  These devices determine the upload stream size either as manually configured by the user or measured automatically when the router reboots.  These devices will not function properly if the bandwidth it believes it is reserving is suddenly made unavailable by the network.  In summary, best-effort traffic is the baseline traffic expectation and developers of Internet products do not expect a situation where a network operator has invented a "worse than best-effort" traffic class -- nor should they.

The issues are, likewise, the same as with protocol discrimination.  

The users are harmed because their network is behaving strangely and they have no way of knowing why.  The devices that they buy at the store with the system requirements of "Broadband Internet Connection" do not work on their connections.  There is no notice before, during, or after their traffic is deprioritized.  And finally, they suffer a very non-technical consumer harm in that they receive less than the plan that was marketed and sold to them.

Innovation is harmed because the access and transit networks continue to behave unexpectedly.  It isn't the network operator who will get the call about the online game or VOIP application that is behaving poorly, it's the software publisher.  I particularly worry about how the binary nature of this "penalty box" will look to users (when all traffic is either prioritized or not, deprioritized traffic suffers significant degredation as only it is fighting for the limited resource).  Normally, a sustained amount of network congestion slows everyone relatively equally and smooths out the effects -- and this effect is rather well recognized as a congestion effect.  Therefore, such behavior will deflect calls for help to publishers and manufacturers of networking products, driving up their costs and decreasing their willingness to invest in new bandwidth-eating applications.

And lastly, this is bad for the future growth of the Internet.  Allow me to editorialize, please -- this will not be technical.  During my career at the worlds largest chip manufacturer, our products (almost by definition) followed a very "Moore's Law" capability curve.  If the CPU overhead was not going to be available, then why develop software with richer detail, smoother video, and deeper sound.  The USA actually does enjoy among the better broadband speeds (not the best, but at the knee of the curve http://news.bbc.co.uk/2/hi/technology/7098992.stm), even though the Cable industry is clearly overpromising and underdelivering (http://arstechnica.com/news.ars/post/20080228-att-talks-serious-smack-about-cable-broadband-speeds.html).  Comcast is sending the signal that the operators of the access  networks are going to tamp down the natural demand-based growth of the internet is as uninteligent as a chip manufacturer saying that they're done making faster chips.  So why would someone release a bandwidth-hungry product into that environment?  Just as the world's largest chip manufacturers enable innovation by trying to stay as far ahead of developers ability to suck-up MIPS as possible, I would expect someone serious about leading in the business of broadband should be doing the same.

Thanks for asking for feedback.  I'm sorry it is not at all positive.  While I do recognize efforts at more transparency and user notification as good things, the method itself fails the standards compatibility test.

Robb Topolski

On Fri, Jun 6, 2008 at 7:04 PM, Livingood, Jason <Jason_Livingood at cable.comcast.com> wrote:

As a follow-up to our presentation of last week, on slide 3 we cited
some of our key focus areas, which were improved/increased transparency,
disclosure, openness, and fairness.  We hope we took some steps in that
direction in the overall slide deck.  Beginning on slide 11 we went into
a good level of detail on technical trials of a new network management
technique, which was protocol-agnostic.

Related to this, we now have a new FAQ on our website about those trials
at
http://help.comcast.net/content/faq/Frequently-Asked-Questions-about-Net
work-Management#technique .  Also, customers in those trial markets have
received an email that explains details about the trial, which is
started yesterday.  Additional information is also available to
subscribers via a link in our Terms of Service, directly to
http://www.comcast.net/terms/network/ .  In addition, on slide 10, we
described speed upgrades for our customers that should now be in place.

As noted during our presentation, we continue to be interested in
specific feedback on the method described.  We hope to be able to share
trial results at some point, and in some TBD form.  Perhaps that will be
possible by the time IETF 72 rolls around.  I know I had some private
follow-ups with folks like Henning as well, and will get to some of
those next week.

Regards
Jason


_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

-- 
Robb Topolski (robb at funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi