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

"Kathy McEwen" <> Thu, 11 November 2010 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2981D3A6919 for <>; Thu, 11 Nov 2010 09:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pe6AaA-I5G2n for <>; Thu, 11 Nov 2010 09:54:58 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 9700D3A689E for <>; Thu, 11 Nov 2010 09:54:58 -0800 (PST)
Received: (qmail 88684 invoked from network); 11 Nov 2010 17:55:11 -0000
Received: from IridescentKathy (kathy@ with login) by with SMTP; 11 Nov 2010 09:55:11 -0800 PST
X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL
X-YMail-OSG: jvJodm8VM1mEzBysKP2rhN.SUx6vFmz7c200Cm2B7fFlTAU 1dMeGQUeUF7VWs7Z2aZhaVECGtbAaMCrLydi7srQiWhXWziBFucx9HmGqFge g5Z.bWuv9ZKYTG2jISfJT1KKDpV_s4if0tdWvPnPd7UeRrNbId6EI1Pn_gud qVPCATj71lEqlLbVma0WI5_PxP2JOBxsnoRGO3d.BfiHw_fmd5.Sh3O6ZHHx or99k0TjRexYde7j9QIzvwFwC3E1Iw.ZaqtIJ1xbdG2FQrittoAkbdyDXDgD F22C3tUFJ1HMWFc1h_8Nf_b9wpGM0
X-Yahoo-Newman-Property: ymail-3
From: "Kathy McEwen" <>
To: "'Mikael Abrahamsson'" <>, "'Mike Hammer \(hmmr\)'" <>
References: <> <> <> <> <> <> <01d801cb8083$8ca250f0$a5e6f2d0$> <> <> <> <> <> <> <> <> <alpine.DEB.1.10.1011111806430.26>
In-Reply-To: <>
Date: Thu, 11 Nov 2010 11:55:14 -0600
Message-ID: <001801cb81c9$9833c3d0$c89b4b70$>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-language: en-us
Cc:, 'httpstreaming' <>,, 'Ingemar Johansson S' <>, "'GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)'" <>
Subject: Re: [httpstreaming] [conex] [dispatch] Q-HTTP
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Nov 2010 17:55:00 -0000

Hello All,

  FYI... ATIS has issued a report on Policy Management, and have started a
Policy Management Focus Group with Assessment and Recommendations, including
numerous descriptions of market need.  Input was gathered from a large
number of contributing operators.  The report was issued in June of this
year, and includes the debates/arguments for managed QoS that also seem to
be bouncing around in this IETF BoF group.  Perhaps some of the ATIS study
work could be useful for the HTTP streaming justification as as
not to duplicate work.  HTTP streaming is one piece of the bigger puzzle.
This IETF BoF group may want to liaison with this ATIS group.

1.1 Problem Statement

As network resources are increasingly stretched by unprecedented growth in
data traffic, Policy management is becoming an important industry topic.
Many service providers are concluding that it is unrealistic to continue
deploying additional capacity at the problem indefinitely. Policy management
is emerging as a potential tool to get more capacity out of installed
networks. Network policies are rules that are defined by the service
provider to control and charge for the resources used for communication
between end-points. Policies can also be used to bind the appropriate
bandwidth, and Quality of Service (QoS) to a given application or
subscriber. Policies can thus be used to control and better ensure the
user's experience in utilizing a service or application, wherever the
service is accessed. For example, a user streaming a video from a video
service can be guaranteed a high quality viewing experience whether they are
viewing the video on a smart phone or a High Definition TV.

Service convergence has been a vision of the communications industry for
years, and recent deployment has begun to translate this vision into
reality. Users can have a single contact number that will terminate on their
landline phone, mobile phone, or computer, depending upon their needs. A
given service can be accessed from a home network, a 3G network halfway
around the world, or from a WiFi hotspot at the coffee shop around the
corner. All of this demonstrates that service convergence is quickly
becoming a practical reality, but only at the basic connectivity level. In
most cases, once a user leaves their local service provider network they are
limited to best effort. In many cases today, that is good enough, and the
popularity of these services is growing exponentially. Growth at this level,
especially from smart phones and netbooks, is already beginning to strain
some networks, and it will only increase over time.


-----Original Message-----
From: Mikael Abrahamsson [] 
Sent: Thursday, November 11, 2010 11:16 AM
To: Mike Hammer (hmmr)
Cc: David Singer;; Kathy McEwen; httpstreaming;; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, JOSEJAVIER
Subject: RE: [conex] [dispatch] [httpstreaming] Q-HTTP

On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote:

> I think the crux of our disagreement here is the difference between 
> what it takes to be an ISP and what it takes to be an access provider.  
> The economics are different.  Apples and oranges.  Saying it works for 
> oranges means it makes sense for apples is a non-sequitor.

For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs
own L1 as well. What do you mean by it?

> <Start political view>
> It is nice that you have a regulated monopoly of L1 in your market, 
> but

It's not a monopoly. Well, the copper is mostly, but the fiber isn't.

> However, comparing blocking (dial-tone means nothing, busy signal 
> does) of QoS guaranteed telephone links with non-QoS based congestion 
> is self-contradictory.  You are in essence saying that on the one hand 
> providers should not have the tools to provide QoS guarantees and on 
> the other hand slapping them for not being able to provide a QoS
> Now how fair is that?

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.

> I would not be so quick to deride the advertizing as false as not very 
> clear, but I do think there could be better education of the public.
> (Have you never tried to explain this to a non-techie and watched 
> their eyes glaze over?)

That's why the IETF should work on tools to show this to people, not give
ISPs tools to screw their customers.

> As for treating traffic equally, you apparently don't care much about 
> real-time interactive applications.  That is your choice.  But, please 
> don't impose that on everyone.

I am fine with packet prioritization within my access line. I have AQM on my
own access line, because it makes my access line perform better for my
packet mix (prioritizes my VoIP and ssh before my data heavy TCP sessions).

The problem I'm having here is that most talk is not about how to make the
customers access line behave better for the customer, it's to have certain
customers traffic be lower prioritized in the distribution and core, so ISPs
can oversubscribe more without customers being able to notice too much.

I resent that.

Mikael Abrahamsson    email: