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

Henry Sinnreich <> Fri, 12 November 2010 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BF503A6A27; Fri, 12 Nov 2010 14:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hPB2h96laebu; Fri, 12 Nov 2010 14:53:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A4B23A69CE; Fri, 12 Nov 2010 14:53:41 -0800 (PST)
Received: by gwb10 with SMTP id 10so1946507gwb.31 for <multiple recipients>; Fri, 12 Nov 2010 14:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=1HLcBErjOlxUfxFyeNXBWeLA8X4pDTs3/EiH3pwFxEY=; b=kU6KJ9vdq0rumbJu6Fv5miE+gVxxd8tq+KeCLBGTM1eHPozkYqpT4hH53teYC22Z6a MThrfF1v5+FnOo5WnJy76QzY7wala0vlx0paHxxOnfJeCicaQ+ybBoZGa57ig03+eMWO n6irQ2o/LsEMaruK/N2gfhx3g1nziBqJ6TwMg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=YGLmpNqZBRg5It+Vb+rHVg9SMrB9iMMuybdrskktv49m0DESNYiCSFyjLMhqoniiA+ 7K5ieOHwrxw/DqDJWhilvYfRmu67EiZVUUIahf4QpXkZ2uPkRpjXw9lPurr1mJ/S1ZHc pgHmZs511NCWBUikIyDMuxUDRySplF4ETZlKg=
Received: by with SMTP id h17mr3916525aga.133.1289602454756; Fri, 12 Nov 2010 14:54:14 -0800 (PST)
Received: from [] ( []) by with ESMTPS id r25sm2703082yhc.0.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 14:54:13 -0800 (PST)
User-Agent: Microsoft-Entourage/
Date: Fri, 12 Nov 2010 16:54:05 -0600
From: Henry Sinnreich <>
To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <>, Mikael Abrahamsson <>, "Mike Hammer (hmmr)" <>
Message-ID: <>
Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP
Thread-Index: AcuBxFjYih2YrN4ESN+MSuHYLVkpagABEd4QADz4Uh8=
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: "" <>, httpstreaming <>, "" <>, Johansson S <>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <>,
Subject: Re: [httpstreaming] [dispatch] [conex] 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: Fri, 12 Nov 2010 22:53:42 -0000

>    I dont see any drawback in trying to anticipate to the future needs...

Yes, but who is supposed pay for this anticipation?
And how do we know the anticipation is not wrong?

This falls into the risk area for business plans, but not for making
standards based on anticipation.

> I dont think real-time was in mind whe Internet was created

>and we need to 
> provide ISPs with new tools like this.
Wrong again IMHO. ISPs would be better advised to fully utilize fiber.

Thanks, Henry

<> wrote:

> Hi,
>    Just a different approach. Think in a traffic jam. I know it would be nice
> to live in a wonderful world with no jams, but they happen. Know compare you,
> going back home from work, and an ambulance with someone dying inside.
> Everybody gets away to let ambulance drive first. And that's OK.
>    Now think on Internet. You are playing a Real-Time game and your neighbours
> are just downloading files. They can afford some amount of traffic loss
> (+delay/jitter) since TCP retransmisions will do the trick (just will take a
> little longer to get the job done) while you cannot afford losing
> (+delaying/jitterin) your traffic because if it happens, your opponent will
> blow you away from the arena. That's the point, all traffic flows are NOT the
> same and need different SLAs.
>   Q-HTTP tries to address both problems:
> - Enable subscriber to measure the SLA is being provided. This by itself is
> nice, since allows e2e players to solve the problem (reducing bit-rate of
> video if possible, for instance)
> - Enables network operators to generate more revenue for "over-requirements".
> I dont think real-time was in mind whe Internet was created and we need to
> provide ISPs with new tools like this.
>    I dont see any drawback in trying to anticipate to the future needs...
>     Saludos,
>          Luismi
> -----Mensaje original-----
> De: [] En nombre de
> Mikael Abrahamsson
> Enviado el: jueves, 11 de noviembre de 2010 18:16
> Para: Mike Hammer (hmmr)
> CC:; httpstreaming;; Ingemar Johansson S;
> Asunto: Re: [dispatch] [conex] [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 guarantee.
>> 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.