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

["Mike Hammer (hmmr)" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, November 11, 2010 12:36 PM
To: Mikael Abrahamsson
Cc: Mike Hammer (hmmr); [e-mail]; Kathy McEwen; httpstreaming;
[e-mail]; 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.