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
- [p2pi] Follow-Up from Comcast Presentation Livingood, Jason
- Re: [p2pi] Follow-Up from Comcast Presentation Robb Topolski
- Re: [p2pi] Follow-Up from Comcast Presentation Nicholas Weaver
- Re: [p2pi] Follow-Up from Comcast Presentation Robb Topolski
- Re: [p2pi] Follow-Up from Comcast Presentation John Leslie
- Re: [p2pi] Follow-Up from Comcast Presentation Joe Touch
- Re: [p2pi] Follow-Up from Comcast Presentation John Leslie
- Re: [p2pi] Follow-Up from Comcast Presentation Joe Touch
- Re: [p2pi] Follow-Up from Comcast Presentation Joel M. Halpern
- Re: [p2pi] Follow-Up from Comcast Presentation John Leslie
- Re: [p2pi] Follow-Up from Comcast Presentation Nicholas Weaver
- Re: [p2pi] Follow-Up from Comcast Presentation Richard Bennett
- Re: [p2pi] Follow-Up from Comcast Presentation Robb Topolski
- Re: [p2pi] Follow-Up from Comcast Presentation Richard Bennett
- Re: [p2pi] Follow-Up from Comcast Presentation Lars Eggert
- Re: [p2pi] Follow-Up from Comcast Presentation Stanislav Shalunov
- Re: [p2pi] Follow-Up from Comcast Presentation Woundy, Richard
- Re: [p2pi] Follow-Up from Comcast Presentation Livingood, Jason
- Re: [p2pi] Follow-Up from Comcast Presentation Livingood, Jason
- Re: [p2pi] Follow-Up from Comcast Presentation Robb Topolski