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

[Henry Sinnreich <[e-mail]>]

>    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
Wrong

>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


On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)"
<[e-mail]> 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: [e-mail] [mailto:[e-mail]] En nombre de
> Mikael Abrahamsson
> Enviado el: jueves, 11 de noviembre de 2010 18:16
> Para: Mike Hammer (hmmr)
> CC: [e-mail]; httpstreaming; [e-mail]; Ingemar Johansson S;
> Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
> 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.