Re: [p2pi] Follow-Up from Comcast Presentation

"Robb Topolski" <robb@funchords.com> Sat, 07 June 2008 15:51 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 BABA63A6B0D; Sat, 7 Jun 2008 08:51:55 -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 803013A6B03 for <p2pi@core3.amsl.com>; Sat, 7 Jun 2008 08:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.247
X-Spam-Level:
X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_50=0.001, 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 HZGrCokeNzLK for <p2pi@core3.amsl.com>; Sat, 7 Jun 2008 08:51:52 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 6641A3A6B0D for <p2pi@ietf.org>; Sat, 7 Jun 2008 08:51:52 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so1544773wfd.31 for <p2pi@ietf.org>; Sat, 07 Jun 2008 08:52:05 -0700 (PDT)
Received: by 10.143.32.4 with SMTP id k4mr559975wfj.251.1212853924903; Sat, 07 Jun 2008 08:52:04 -0700 (PDT)
Received: by 10.142.186.7 with HTTP; Sat, 7 Jun 2008 08:52:04 -0700 (PDT)
Message-ID: <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com>
Date: Sat, 07 Jun 2008 10:52:04 -0500
From: Robb Topolski <robb@funchords.com>
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu>
MIME-Version: 1.0
References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu>
Cc: p2pi@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
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="===============1477956478=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

> THis is a RIDICULOUS notion.
>

I would have expected a better choice of words, Nick.



> And "Fairness" doesn't have to be nebulous.  "In the periods of congestion,
> when there are N users competing for traffic, no user will get more than 1/N
> - epsilon of the available bandwidth, measured as a running average over 10
> seconds and 10 minutes".


It seems that we both agree this would be an improvement, but still not good
enough unless codified somewhere (suggested, vetted, approved, and made
Internet Standard by the IETF).



> A nice concrete definition, that would INSTANTLY prioritize small flows
> over large flows, and interactive flows over bulk flows, when examined
> between users.  Its what users really expect when you talk about "fairness".


I think you will agree that users don't know about flows, and developers
might think fairness means the equal opportunity to send at any given moment
despite what happened milliseconds ago.



>
>  9-1-1 scenario (emergency call, 999, etc.)
>>
>
> So you'd rather her not be able to make a VoIP 911 call because someone
> ELSE on the same subnet is running BitTorrent grabbing "Indiana Jones and
> the Latest McGuffin"?
>

Anything that is popular is popular because it works on the Internet --
warts and all.  There is nothing out there that depends on prioritization as
the differentiating factor between "working" and "not working."
Prioritization simply makes such real-time applications more robust.  99% of
the time, the Internet is fine.  Prioritization helps certain applications
during that 1% of the time.  (brown numbers disclaimer)


Yes, we can all dream of the utopia where the picture upload knows that its
> a picture upload and the VoIP call knows its a VoIP call and the networking
> signaling takes care of itself.


This is not my utopia.



> But with all the crappy NAT boxes (eg, which randomly inject RST packets
> into active flows!), crappy end host software, and crud in between,


The solution to interference by non-Standards-conforming devices should not
be adding additional non-standards-conforming devices.


if you want the VoIP call to have priority, the ISP must infer that it is a
> VoIP call and treat it as such, because otherwise the old devices, with
> their many limitations, will mess up your signaling.


You have missed my point, and perhaps others did to.  Note the word priority
does not exist in the following paragraph, nor is any signalling mentioned:

Best-effort is the baseline expectation of innovators creating products for
the Internet -- even with some congestion thrown in.  They design their
products to work in such a network.  They cannot expect that network
operators will invent worse-than-best-effort class that dramatically changes
the characteristics of the network from one moment to the next.



> But until then, INTER user fairness is essential, because without it, the
> net can't operate in the flat-rate billing model.


I'm certain that it can, if not for all, for most.

According to the NCTA, this is a problem caused by a very few users.  That
statement doesn't pass the smell test, however.  I think that the market
demands and competitive abilities for more symmetrical connections in the
last mile have outstripped Cable's ability to keep up with it.

I think that these are not technical problems, these are willful business
choices in approaching the market: Cable Internet is shaping the future by
shaping the traffic in the present because it serves many of their business
interests to do so.  Perhaps the business interest is simply to avoid
increasing costs related to bandwidth growth; perhaps it is more.  Either
way, the follow-on consequence is limiting the options to consumers who are
distracted from watching television by the many competing choices on the
Internet.

The beauty of the Internet Standards is that they hold no such motives or
bias.  They are EE/CS's answer to MBAs as to what should and should not be
happening on the 'Net.


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.
>>
>
> If you want a DEDICATED 10 Mbps, rather than a statistically multiplexed 10
> Mbps, pay for it!  It costs ~$1000 a month or so for a reason.  Or
> pay-per-bit, in which case the ISP would be happy to not do any traffic
> shaping at all, because your bit is worth the same as your neighbors.
>
> But in the flat rate world, heavy users traffic is less valuable to the
> ISP, and damaging to the light users.  Remember, you may have 5000+ users
> sharing a single 1 Gbps uplink.  Yes, they have a "16 Mbps" download, but it
> only works because not everybody is downloading at full rate at the same
> time.
>

Nicholas, everything you said above is true.  It is also beside the point to
everyone on this list -- we understand the technical implications of the
shared nature of their Internet connection.  Grandma and Grandpa Farmer or
Mr. and Mrs. Factory Worker do not and should not have to understand
overbooking (or statistical multiplexing, or bandwidth aggregating, or
whatever).

The ISPs control the sizes of the shared pools of bandwidth, the number of
consumers who share it, the prices of admission, and the size of the pipes
between a subscriber and the pool.  They have total control and purview over
those variables.  Controlling these variables to ensure that everyone has a
good experience is Reasonable Network Management.

Regardless of how ISPs structure the offering, the end effect has to be
Internet access that works reliably for subscribers who are using the
Internet within those parameters. A major ISP offering Internet service that
fluctuates wildly between working and not-working well is bad for the entire
community!

More and more, people and businesses rely on the internet.  If it becomes
perceived as unreliable, it is much less valuable and the network will
shrink. Today, common advice in VOIP forums is to not rely on your provider
for 9-1-1 calls.  Regardless of the actual soundness of such advice, we
should be working toward a day where such advice is universally dismissed
due to the actual increased reliability of Internet services and
infrastructure.

Users, unnovators, service providers, and even operators should all be able
to rely on the fact that the Internet does not and will not behave
unpredictably from one segment to the next, from one moment to the next, or
from one protocol to the next.


> NO network device should, or CAN assume that the bandwidth is fully
> committed to it.


That is good advice, but it is not yet understood.  Even the most savvy
network developers expect that once the network is accurately detected or
described into its configuration, that it does not change from moment to
moment.

There's a story some of the Comcast guys told me about Apple iChat and
Powerboost.  Your advice would have helped the iChat developers avoid some
headaches.

But, you weren't thinking of these things -- you were thinking about
congestion...


> Otherwise, why would you have congestion control?
>

Unlike your advice above, everyone understands that congestion happens.
Some congestion on the Internet is expected from time to time, and
developers work in enough robustness.  But, nothing is really expected to
work well through a system that is *cronically clogged*.  Current
congestion-control algorithms are quick and are sufficient for taming
momentary spikes in congestion.

Comcast is not talking about relieving spikes of congestion.  Instead, they
are moving toward *prolonged congestion as a planned operational mode*.  As
I pointed out, they have announced that they are tripling their upload
speeds (presumably even though the underlying shared pool of bandwidth has
remained the same as these increases are not related to DOCSIS3
deployment).

Comcast would only need to invent this new method unless they have abandoned
expectations to keep the amount of available bandwidth well ahead of their
consumers' demand for it.

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