Re: [p2pi] Follow-Up from Comcast Presentation

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

On Jun 6, 2008, at 7:09 PM, Robb Topolski wrote:

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

THis is a RIDICULOUS notion.

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

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


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

So you'd rather her not be able to makFrom p2pi-bounces at ietf.org  Fri Jun  6 19:56:03 2008
Return-Path: <p2pi-bounces at ietf.org>
X-Original-To: p2pi-archive at ietf.org
Delivered-To: ietfarch-p2pi-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1FEB63A68C1;
	Fri,  6 Jun 2008 19:56:03 -0700 (PDT)
X-Original-To: p2pi at core3.amsl.com
Delivered-To: p2pi at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EC5313A6905
	for <p2pi at core3.amsl.com>; Fri,  6 Jun 2008 19:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.336
X-Spam-Level: 
X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 CSrfATvSMGUg for <p2pi at core3.amsl.com>;
	Fri,  6 Jun 2008 19:56:00 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU
	[192.150.186.11])
	by core3.amsl.com (Postfix) with ESMTP id 003413A68C1
	for <p2pi at ietf.org>; Fri,  6 Jun 2008 19:55:59 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake [192.150.186.11])
	by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id
	m572u7bf001930; Fri, 6 Jun 2008 19:56:07 -0700 (PDT)
Message-Id: <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3 at icsi.berkeley.edu>
From: Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>
To: Robb Topolski <robb at funchords.com>
In-Reply-To: <3efc39a60806061909n11a65eafnce88df7c73c30639 at mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Fri, 6 Jun 2008 19:56:08 -0700
References: <45AEC6EF95942140888406588E1A6602045CBA5E at PACDCEXCMB04.cable.comcast.com>
	<3efc39a60806061909n11a65eafnce88df7c73c30639 at mail.gmail.com>
X-Mailer: Apple Mail (2.924)
Cc: p2pi at ietf.org, "Livingood, Jason" <Jason_Livingood at cable.comcast.com>,
	Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>
Subject: Re: [p2pi] Follow-Up from Comcast Presentation
X-BeenThere: p2pi at 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 at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi at ietf.org>
List-Help: <mailto:p2pi-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>,
	<mailto:p2pi-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces at ietf.org
Errors-To: p2pi-bounces at ietf.org


On Jun 6, 2008, at 7:09 PM, Robb Topolski wrote:

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

THis is a RIDICULOUS notion.

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

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


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

So you'd rather her not be able to make a VoIPe a VoIP 911 call because  
someone ELSE on the same subnet is running BitTorrent grabbing  
"Indiana Jones and the Latest McGuffin"?

In fact, this is EXACTLY the case why ISPs need to do both INTER user  
fairness (to ensure that everyone gets some reasonable allocation,  
because TCP DOES NOT PROVIDE THIS AS THE APPLICATIONS ARE USED!) and  
INTRA-user shaping to prioritize small flows (a simple "prioritize  
smaller flows" instantly ensures that VoIP still works).

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.  But with all the  
crappy NAT boxes (eg, which randomly inject RST packets into active  
flows!), crappy end host software, and crud in between, 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.

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

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

And notions of network enforced fairness should not mess up the dream  
of devices which do proper scheduling: NO network device should, or  
CAN assume that the bandwidth is fully committed to it.  Otherwise,  
why would you have congestion control?


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


 911 call because  
someone ELSE on the same subnet is running BitTorrent grabbing  
"Indiana Jones and the Latest McGuffin"?

In fact, this is EXACTLY the case why ISPs need to do both INTER user  
fairness (to ensure that everyone gets some reasonable allocation,  
because TCP DOES NOT PROVIDE THIS AS THE APPLICATIONS ARE USED!) and  
INTRA-user shaping to prioritize small flows (a simple "prioritize  
smaller flows" instantly ensures that VoIP still works).

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.  But with all the  
crappy NAT boxes (eg, which randomly inject RST packets into active  
flows!), crappy end host software, and crud in between, 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.

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

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

And notions of network enforced fairness should not mess up the dream  
of devices which do proper scheduling: NO network device should, or  
CAN assume that the bandwidth is fully committed to it.  Otherwise,  
why would you have congestion control?


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