Re: [httpstreaming] [dispatch] Q-HTTP

"GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <> Wed, 10 November 2010 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04AB33A6A3B; Tue, 9 Nov 2010 23:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.682
X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9zrA5gwSfROV; Tue, 9 Nov 2010 23:25:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 07CDA3A6A40; Tue, 9 Nov 2010 23:24:47 -0800 (PST)
Received: from ( []) by (8.14.3/8.14.3/ICT) with ESMTP id oAA7P7ZO010933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Nov 2010 08:25:07 +0100
Received: from ([]) by ([]) with mapi; Wed, 10 Nov 2010 08:25:07 +0100
To: Mark Watson <>, Kathy McEwen <>
Date: Wed, 10 Nov 2010 08:25:05 +0100
Thread-Topic: [httpstreaming] [dispatch] Q-HTTP
Thread-Index: AcuAjmy2DbYTXxLsQwO+PWlAAVcPSgAGMA9g
Message-ID: <>
References: <> <> <> <> <> <> <> <01d801cb8083$8ca250f0$a5e6f2d0$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: es-ES
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on
Cc: "" <>, httpstreaming <>, "" <>, Ingemar Johansson S <>
Subject: Re: [httpstreaming] [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: Wed, 10 Nov 2010 07:25:40 -0000

Adaptable non-interactive video delivery is suitable for congestion problems, but what about latency?
It is no possible to adapt to a large latency reducing video resolution.

I refer to the "interactive video" scenario, for example a virtualized videogame.
Video must be delivered to the final user quickly and final user press 
action controls which change the video in real-time. If final user wants to play to
"Street fighter" in a videoconsole located in the cloud, it is needed a mechanism for
Measuring and adjust latency, in both directions.

Even with overall more bandwidth than needed, the problem persists.

- Jose Javier

-----Mensaje original-----
De: Mark Watson [] 
Enviado el: miércoles, 10 de noviembre de 2010 5:19
Para: Kathy McEwen
CC: Lars Eggert; David Singer; Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming;;
Asunto: Re: [httpstreaming] [dispatch] Q-HTTP

Sent from my iPad

On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" <> wrote:

> One problem with the voice analogy is that the sheer volume of data 
> traversing the web today is not driven by's video...and 
> it's not even a fraction of the viewing that folks are doing of 
> broadcast content.  A solution that depends on "simply" having too 
> much bandwidth, is that someone is paying for it.  Eventually it hits 
> someone's pocket books....and if there isn't sufficient revenue to cover the costs, the too much does degrade.
> Today the mass media is consumed via cheap broadcast technologies... 
> why shouldn't the web (fixed and mobile) be as cheap AND as good??

It should, the question is what is the cheapest way to do it. QoS is expensive too. I tend to agree with the thesis below that history is telling us that avoiding scarcity in the first place is cheaper than rationing here.


> -----Original Message-----
> From: 
> []
> On Behalf Of Lars Eggert
> Sent: Tuesday, November 09, 2010 8:02 PM
> To: David Singer
> httpstreaming;;
> Subject: Re: [httpstreaming] [dispatch] Q-HTTP
> On 2010-11-9, at 18:31, David Singer wrote:
>> It is that there are two ways to solve a real-time bandwidth need.  
>> One is
> to reserve bandwidth, manage QoS and so on;  one gets protocols and 
> systems like diffserv, ATM, and so on.  The other is simply to have 
> 'too much' of the resource.  Though it feels wrong, the latter often 
> ends up being the cheaper and easier solution.  So, for example, voice 
> over IP is getting used quite a lot, and to good effect, on the 
> internet today not because we have successfully deployed any bandwidth 
> reservation or QoS management protocols and systems, but because the 
> available bandwidth is, for the most part, greatly in excess of what 
> is needed, and the systems can adapt in real-time to what they get 
> (rather than asking for what they want).  The same is true for 
> multimedia delivery;  the complexity of RTP + TCP friendliness + QoS 
> management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed.
> Fully agreed. 
> Folks who like pictures can take a look at 
>, which gives much 
> the same argument.
> Lars
> _______________________________________________
> httpstreaming mailing list