Re: [p2pi] Follow-Up from Comcast Presentation

"Robb Topolski" <robb@funchords.com> Tue, 10 June 2008 01:44 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C3E3A6848; Mon, 9 Jun 2008 18:44:08 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C0A3A6848 for <p2pi@core3.amsl.com>; Mon, 9 Jun 2008 18:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level:
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXBTRllCOZVd for <p2pi@core3.amsl.com>; Mon, 9 Jun 2008 18:44:05 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 4CA043A67AD for <p2pi@ietf.org>; Mon, 9 Jun 2008 18:44:04 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so2561710wfd.31 for <p2pi@ietf.org>; Mon, 09 Jun 2008 18:44:25 -0700 (PDT)
Received: by 10.142.107.1 with SMTP id f1mr1770727wfc.10.1213062265458; Mon, 09 Jun 2008 18:44:25 -0700 (PDT)
Received: by 10.142.186.7 with HTTP; Mon, 9 Jun 2008 18:44:25 -0700 (PDT)
Message-ID: <3efc39a60806091844m54dd2dc5w3107ea875efc0c40@mail.gmail.com>
Date: Mon, 09 Jun 2008 18:44:25 -0700
From: Robb Topolski <robb@funchords.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
In-Reply-To: <45AEC6EF95942140888406588E1A6602045CBA87@PACDCEXCMB04.cable.comcast.com>
MIME-Version: 1.0
References: <45AEC6EF95942140888406588E1A6602045CBA87@PACDCEXCMB04.cable.comcast.com>
Cc: p2pi@ietf.org
Subject: Re: [p2pi] Follow-Up from Comcast Presentation
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1959139155=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

2008/6/9 Livingood, Jason <Jason_Livingood@cable.comcast.com>:

> First, I would say that it seems that this example user should configure
> their home gateway router to allocate a specific amount of LAN bandwidth for
> their VoIP service, so that their VoIP service would not be overwhelmed by
> and negatively affected by the upload of several GB of digital photos.
>

Right, but such devices need to know both numbers in order to reserve it.
What's left is the unreserved bandwidth -- the total minus the reserved.

The protocol-agnostic method has the effect of lowering the total, rendering
any such settings designed to reserve bandwidth meaningless..


Secondly, without any form of network management (current or future), the
> heavy use of  whatever apps by a few people at times of congestion would
> interfere with the same VoIP call.
>
>
As I've said before, network developers expect an Internet with occasional
congestion.  An application that is not tolerant of some congestion won't
last on the Internet very long.



> As we stated up at MIT, our trial is NOT applying rate limits to the
> subscribers.  So for example, we're NOT taking a 16Mbps/2Mbps customer
> down to 1Mbps/512Kbps.  The user's bits we are talking about are simply
> assigned a lower QoS for some period of time, assuming (1) that the network
> is in a near-congestion state and (2) the user has crossed a specific
> threshold of usage for a specific period of time (both conditions must be
> met).
>
>
Which is like saying that instead of pot-holing the road, you're letting air
out of their tires.  Whether they get poor performance due to throttling or
poor performance due to dropping or delaying packets, the result is that
they get poor performance.



> But perhaps more importantly, devices that "assume" that the network's
> bandwidth is a fixed constant are flawed devices.
>
> I'm inclined to agree with you.  However, most of the devices out there
disagree with "us" -- and we should recognize that.


> Actually, you may be surprised to discover that the ISP is often the *first
> *call for many of these customers.
>
> OF COURSE it is.  Let's see, you work for an ISP.  I worked for a
networking software/hardware vendor.  From wherever I sit, the grass is
always greener "over there." :-)

Unfortunately, you have made a few statements to the effect that our
> investment in our network is largely static, meaning that every few years we
> decide whether or not to invest in the network.
>
> Please go back and read again.

When the subject has come up, I've given you credit for spending the most
money out of the list of MSOs on infrastructure growth.  I AM WORRIED that
innovations like Deep Packet Inspection will cause such investment to
flatten -- even in Comcast -- but I have not taken the position that it
stopped investment in it.

I'm a Comcast Fan, and I remain a customer.  I got DSL in a deal for my
roommate, but I choose to use Comcast. I've posted that fact quite
publically.  But a line was crossed here that ISPs shouldn't cross, and I
documented it.  It's important, doubly-so given Comcast's leadership
position in its industry.  I very much want Comcast to remain the
open-ports, low-interference ISP it has always been.

As more and more *ideas *about stuff to put in the middle of the network to
monitor and change and monetize what's happening on OUR Internet, the more
concerned I become about the future.  Because no matter how small
industry-giant Comcast decides it is willing to intrude, the farther it
pushes the bounds that poorer or less disciplined ISPs feel empowered for
their more intrusive interceptions.  Keeping Comcast's large network one
that is conforming to the standards and qualified practices helps keep
everyone's network that way.

I've been a fan.  I am a fan.  And I plan to be a fan.  But I've also been
honest and I've been clearly rooting for you to use your leadership position
for things that are good for the net.


> When parts of the network approach pre-set utilization numbers, a well
> tested process kicks in automatically to upgrade these portions of the
> network.
>
> As I said before, I do know this.  I've quoted Tony Werner in 2-year-old
articles on this very topic.  I know that you upgrade regularly -- so it's
not me that you're arguing with.

Robb





-- 
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