Re: [p2pi] ietf mandate ...

["Robb Topolski" <robb at funchords.com>]

On Sun, Jun 8, 2008 at 1:28 PM, Don Bowman <don at sandvine.com> wrote:

> personally I have a real problem with the idea of 'flow destination
> selection signalled from the network for times of congestion
> or locations of cost', I think that it will be very hard, these
> things change dynamically (mobile ip, load, network failovers,
> ospf changes, ...). Thus I am not a fan of trying to build the
> 'best cost path' approach (despite having designed and deployed
> Product at large scale that did this)... although its pragmatic
> For certain classes of network, its not a generic solution.


Don,

Although your suggestion comes with so many asterisks and concerns that I
don't quite know what to make of it all, *I like the gist of it*.  (If
congestion control really needs to be fixed, that is, which I am trending
toward the doubful side as events unfold.)

However, thinking about your suggestion, I have this question:  Can you help
me understand it by contrasting it to (my understanding, at least, of) DSCP
/ DiffServ?

Instead of a scavenger class, why couldn't "best-effort" or undesignated
traffic *be *the scavenger class traffic, and allow consumers to designate
some relatively tiny amount (eitheFrom p2pi-bounces at ietf.org  Sun Jun  8 14:10:08 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 900083A68DF;
	Sun,  8 Jun 2008 14:10:08 -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 2B95E3A68DF
	for <p2pi at core3.amsl.com>; Sun,  8 Jun 2008 14:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.262
X-Spam-Level: 
X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=0.714, 
	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 RjJIl7V07Izv for <p2pi at core3.amsl.com>;
	Sun,  8 Jun 2008 14:10:06 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174])
	by core3.amsl.com (Postfix) with ESMTP id ED8D13A6890
	for <p2pi at ietf.org>; Sun,  8 Jun 2008 14:10:05 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so1977191wfd.31
	for <p2pi at ietf.org>; Sun, 08 Jun 2008 14:10:20 -0700 (PDT)
Received: by 10.142.89.13 with SMTP id m13mr1089746wfb.338.1212959420787;
	Sun, 08 Jun 2008 14:10:20 -0700 (PDT)
Received: by 10.142.186.7 with HTTP; Sun, 8 Jun 2008 14:10:20 -0700 (PDT)
Message-ID: <3efc39a60806081410i340fc5c2mf27da8eefebbc0cf at mail.gmail.com>
Date: Sun, 8 Jun 2008 16:10:20 -0500
From: "Robb Topolski" <robb at funchords.com>
To: "Don Bowman" <don at sandvine.com>
In-Reply-To: <EB618291F3454E4DA10D152B9045C017014CB24B at exchange-2.sandvine.com>
MIME-Version: 1.0
References: <mailman.5529.1212912021.4906.p2pi at ietf.org>
	<EB618291F3454E4DA10D152B9045C017014CB24B at exchange-2.sandvine.com>
Cc: p2pi at ietf.org
Subject: Re: [p2pi] ietf mandate ...
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: multipart/mixed; boundary="===============1900446295=="
Sender: p2pi-bounces at ietf.org
Errors-To: p2pi-bounces at ietf.org

On Sun, Jun 8, 2008 at 1:28 PM, Don Bowman <don at sandvine.com> wrote:

personally I have a real problem with the idea of 'flow destination
selection signalled from the network for times of congestion
or locations of cost', I think that it will be very hard, these
things change dynamically (mobile ip, load, network failovers,
ospf changes, ...). Thus I am not a fan of trying to build the
'best cost path' approach (despite having designed and deployed
Product at large scale that did this)... although its pragmatic
For certain classes of network, its not a generic solution.

Don, 

Although your suggestion comes with so many asterisks and concerns that I don't quite know what to make of it all, I like the gist of it.  (If congestion control really needs to be fixed, that is, which I am trending toward the doubful side as events unfold.)

However, thinking about your suggestion, I have this question:  Can you help me understand it by contrasting it to (my understanding, at least, of) DSCP / DiffServ?

Instead of a scavenger class, why couldn't "best-effort" or undesignated traffic be the scavenger class traffic, and allow consumers to designate some relatively tiny amount (either by monthly allocation or daily percentage or whatever) for Expedited Forwarding.  (The EF quota would be an amount definitely enough to make VOIP and head-to-head games work -- since that's the practical example that we have today -- but the choice of what to prioritize is the users' and not the ISP's purview.)  

This idea could be built upon further with a second larger quota with some "average" amount for a better-than-default Assured Forwarding class.  We could think of this as an "very interactive class" or perhaps a "live streaming" class.   What's left is "best-effort." 

Users (through their applications) could identify which packets are which.  To prevent abuse, the network should ignore the markings if the user is above their quota for that DSCP.  

An opt-in DPI device at the carrier could help consumers get on board without further configuration.  It would feature a one-size-fits-most preset that applies for most users. Otherwise, consumers could enable or upgrade their applications and equipment to enable packet marking to fit their own desires. 

-- 
Robb Topolski (robb at funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi