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

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Wed, 17 November 2010 16:59 UTC

Return-Path: <richard_woundy@cable.comcast.com>
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 C81263A692A; Wed, 17 Nov 2010 08:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.463
X-Spam-Level:
X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, 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 oteLRyYhRqfM; Wed, 17 Nov 2010 08:59:35 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 97E903A6941; Wed, 17 Nov 2010 08:59:34 -0800 (PST)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.105431181; Wed, 17 Nov 2010 12:00:18 -0500
Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Wed, 17 Nov 2010 12:00:18 -0500
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP
Thread-Index: AQHLhi0Oh89LDIYhB0GG7XamnkwDvZN15DxA
Date: Wed, 17 Nov 2010 17:00:16 +0000
Message-ID: <1CA25301D2219F40B3AA37201F0EACD1034F4E@PACDCEXMB05.cable.comcast.com>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.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> <alpine.DEB.1.10.1011111806430.2639@uplift.swm.pp.se> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <alpine.DEB.1.10.1011111957580.2639@uplift.swm.pp.se> <002a01cb81e1$40e58740$c2b095c0$@com> <alpine.DEB.1.10.1011112150370.2639@uplift.sw m.pp.se> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> <alpine.DEB.1.10.101116225431 0.1154@uplift.swm.pp.se> <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> <alpine.DEB.1.10.1011170849000.1154@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.1011170849000.1154@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.191.223.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 17 Nov 2010 17:05:38 -0800
Cc: httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>
Subject: Re: [httpstreaming] [conex] [dispatch] 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: Wed, 17 Nov 2010 16:59:35 -0000

> That is true, but the reason for transit prices being high is usually a political problem, not a technical one.

Just curious -- where is this conversation going? Are we to assume the same economic and political conditions throughout the world?

Personally, I am not convinced that the HTTP streaming "quality of experience" necessarily implies Internet QoS. But I thought we discuss IETF issues here, not UN issues (or OECD issues).

-- Rich

-----Original Message-----
From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Mikael Abrahamsson
Sent: Wednesday, November 17, 2010 2:57 AM
To: Benjamin Niven-Jenkins
Cc: httpstreaming; conex@ietf.org
Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP

On Wed, 17 Nov 2010, Benjamin Niven-Jenkins wrote:

> My point was that if you look at global transit prices they are 
> typically a few dollars a Mbps in the west. That pricing is not 
> universal across the globe.

That is true, but the reason for transit prices being high is usually a 
political problem, not a technical one.

No matter of talk about how nice QoS is hides the fact that if you're 
congesting anything else than the customer port, you're not giving the 
customer what he or she purchased. Also, the Internet became successful 
because it adhered to "keep it simple stupid" principle. The suggestions 
I've seen so far here is anything but simple and usually involves quite 
intrusive changes in equipment and business models.

I totally fail to see how making the network and payment models more 
complicated will make the network better. Money (capex and opex) should be 
spent on upgrading capacity and keeping the network simple, not trying to 
make the impact of too little capacity less noticable.

The network that has constrained access bandwidth (for instance mobile 
networks) already have advanced per-user queuing that assures "fair 
access" to the media. I would imagine cable networks have the same.

I see little reason to implement support for this in end-hosts, end-hosts 
should be greedy because that's how things work in real life. End-hosts 
are under the control of the end-user and thus can't be trusted to do "the 
right thing" when it comes to "fairness".

So anyone who wants to underprovision their network need to make sure they 
have 3GPP style bearer and scheduling concept working in their network to 
handle how resources are handled, we don't need new mechanisms for this, 
it's already been available for 10 years.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex