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

"Mike Hammer (hmmr)" <hmmr@cisco.com> Thu, 11 November 2010 18:03 UTC

Return-Path: <hmmr@cisco.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 4D16B3A69C2; Thu, 11 Nov 2010 10:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.561
X-Spam-Level:
X-Spam-Status: No, score=-11.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8]
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 8l5NwAQipghl; Thu, 11 Nov 2010 10:03:28 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 02AF43A6969; Thu, 11 Nov 2010 10:03:27 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAN++20ytJV2Z/2dsb2JhbACiRXGmN5tUhUoEhFqJDw
X-IronPort-AV: E=Sophos;i="4.59,184,1288569600"; d="scan'208";a="180904514"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2010 18:03:54 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oABI3sKq000789; Thu, 11 Nov 2010 18:03:54 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 12:03:54 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Nov 2010 12:03:53 -0600
Message-ID: <C4064AF1C9EC1F40868C033DB94958C7031F1212@XMB-RCD-111.cisco.com>
In-Reply-To: <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP
Thread-Index: AcuBxvZJyzWpf/DyTPmgPL/g414AyAAAYEpw
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> <alpine.DEB.1.10.1011111806430.26 39@upli ft.swm.pp.se > <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com>
From: "Mike Hammer (hmmr)" <hmmr@cisco.com>
To: "David Singer" <singer@apple.com>, "Mikael Abrahamsson" <swmike@swm.pp.se>
X-OriginalArrivalTime: 11 Nov 2010 18:03:54.0565 (UTC) FILETIME=[CDC29750:01CB81CA]
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: dispatch@ietf.org, httpstreaming <httpstreaming@ietf.org>, conex@ietf.org, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" <jose_javier.garcia_aranda@alcatel-lucent.com>
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: Thu, 11 Nov 2010 18:03:29 -0000

David,

Yes, I have to agree that there are several approaches to how packets
are handled and they have to be balanced so you don't starve one or
another.

All packets can't be first in the queue, so some preferences and
ordering will take place.

There seems to be a gap between what a customer thinks they paid for and
what the provider thought they offered at that price.  The latter has to
make assumptions about traffic volume and mix and plan pricing and costs
to come out positive, or they won't be in business very long.  But, as
most traffic planners know, what you plan for and what traffic you get
can vary widely, especially with data.  If you want hard guarantees,
then you need to have private roads, but that is much more expensive and
most folks aren't willing to pay for it.

There are certain cases where without the QoS the service just doesn't
work.  For those, a user may be willing to pay to ensure the service.
If the network is engineered properly, then such services only take up a
fraction of the network.  If it is too large a share, does that mean the
QoS mechanism is bad?  No, it means the traffic engineering and
implementation is bad.  So, let us put the blame where it is due.  

The IETF should be about designing good tools.  Not attempting to
control bad usage of good tools.

My experience personally.  My package is 20Mb up and 20 Mb down.  What
do I normally get is 5Mb up and 10Mb down.  Am I upset?  No, because the
applications generally work.  There are tools out there to measure that.
If your provider is not even in the ball park of what he is offering,
then yeah, you need to switch.

Mike



-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Thursday, November 11, 2010 12:36 PM
To: Mikael Abrahamsson
Cc: Mike Hammer (hmmr); dispatch@ietf.org; Kathy McEwen; httpstreaming;
conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA,
JOSEJAVIER (JOSE JAVIER)
Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP


On Nov 11, 2010, at 18:15 , Mikael Abrahamsson wrote:
> 
> I don't want QoS guarantees, I want *all* my packets delivered,
expediently, regardless if my neighbour is filling up his pipe or not. I
have paid for it, and I want it DELIVERED. The postal office doesn't get
to choose which of my letters it's ok to delay or throw away, they
should just deliver them. Same with my ISP.
> 

It's interesting you say this in the context of real-time media, because
I believe a network can give time guarantees ("any packet I deliver on
this will be delivered within x ms") or delivery guarantees ("all
packets will eventually be delivered") but it's hard (impossible, maybe)
to do both.

eMail is an assured store-and-forward service.  IP packets are not.
Most users are unwilling to pay for guaranteed bandwidth availability to
an ISP, who in turn would have to pay for guaranteed bandwidth upstream,
and so on.  

Personally, I want my fair share of the shared 'roads' no matter how
many others are sharing them, and I expect the 'last mile' personal link
to have (at least) the capacity that was sold to me.


David Singer
Multimedia and Software Standards, Apple Inc.