IETF Logo Mail Archive

Re: [httpstreaming] [dispatch] [conex] Q-HTTP

Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk> Tue, 16 November 2010 20:46 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B715F3A6E56; Tue, 16 Nov 2010 12:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 ooDOTio9Q5Kg; Tue, 16 Nov 2010 12:46:25 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id ACA923A6E51; Tue, 16 Nov 2010 12:46:24 -0800 (PST)
Received: from host86-156-248-113.range86-156.btcentralplus.com ([86.156.248.113] helo=unknown-00-22-43-25-f9-66.home) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1PISQl-0006pf-KX; Tue, 16 Nov 2010 20:47:08 +0000
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <DBB1DC060375D147AC43F310AD987DCC180E504600@ESESSCMS0366.eemea.ericsson.se> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <EAA2CFBF-9434-4E52-A586-7AE5F665A9DF@apple.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <C4064AF1C9EC1F40868C033DB94958C7031F0C1F@XMB-RCD-111.cisco.com> <EF84DC37-8CB6-4DB7-85AC-E091D90FF075@apple.com> <C4064AF1C9EC1F40868C033DB94958C7031F0CA2@XMB-RCD-111.cisco.com> <alpine.DEB.1.10.1011102303170.2639@uplift.swm.pp.se> <C4064AF1C9EC1F40868C033DB94958C7031F10D0@XMB-RCD-111.cisco.com> <alpine.DEB.1.10.1011111616310.2639@uplift.swm.pp.se> <C4064AF1C9EC1F40868C033DB94958C7031F1154@XMB-RCD-111.cisco.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> <C4064AF1C9EC1F40868C033DB94958C7032A5ABE@XMB-RCD-111.cisco.com> <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com>
In-Reply-To: <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <E9A54517-2DE2-4E6C-9512-25C28ED62139@niven-jenkins.co.uk>
Content-Transfer-Encoding: quoted-printable
From: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Tue, 16 Nov 2010 20:47:06 +0000
To: David Singer <singer@apple.com>
X-Mailer: Apple Mail (2.1078)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: httpstreaming <httpstreaming@ietf.org>, conex@ietf.org
Subject: Re: [httpstreaming] [dispatch] [conex] Q-HTTP
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2010 20:46:25 -0000

David,

On 16 Nov 2010, at 19:40, David Singer wrote:

> OK, so my example was slightly humorous.  But in general I think the claim that you can give preferential treatment -- preferential allocation of bandwidth -- to certain traffic simply because of its type is doubtful.  
> 
> Remember, this issue only comes up when there is a shortage;  and the thesis that I should be short-changed more (treated worse) than you because you are doing a real-time operation and I am not, is doubtful.

One solution that I have deployed in a previous life & that I know is used by other ISPs is hierarchical shaping at the BNG.

Each "subscriber" gets a "fair" allocation of bandwidth but they (or their ISP via their service bundle) choose how to prioritise packets within their allocation.

You can then prioritise your download over your daughter's VoIP and Mike can prioritise his VoIP over his daughter's download while you both get the bandwidth you have individually "paid" for.

Everyone's a winner :-)

Ben

v2.23.0 | Report a Bug | By Email