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@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<http://help.comcast.net/content/faq/Frequently-Asked-Questions-about-Network-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@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
>



-- 
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/

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