Re: [httpstreaming] [dispatch] Q-HTTP

Hi,

Agree to Ingemar's view -- congestion and queuing delay are closely related. The "QoS by over-provisioning" argument is however only half-true, because there are networking domains, such as wireless mobile (as already mentioned here), where capacity demand is dynamic, resources are assigned dynamically, depending on different factors, and some capacity scarcity can still be expected even in future networks.

But independent of that, for the virtualized video game, I don't think you are actually interested in measuring/adjusting latency as long as there are AQM *and* good enough incentives for other applications to yield to your important, bursty video game traffic within a few RTTs.

Such incentives for adapting your sending behavior can apply to both transport and application layer behavior, i.e., congestion indication would trigger codec/format parameter switching. There are interesting questions on the time scale of such adaptations, i.e., in relation to transport layer response to congestion.

Best regards,

Dirk

> -----Original Message-----
> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf
> Of Ingemar Johansson S
> Sent: Wednesday, November 10, 2010 9:15 AM
> To: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Mark Watson; Kathy McEwen
> Cc: httpstreaming; dispatch@ietf.org; David Singer; conex@ietf.org
> Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP
> 
> Hi
> 
> I see congestion and delay as two sides of the same coin. I believe
> that some of the good to do's in Lars slides mentioned the use of AQM
> and avoid long buffers. This of course assumes that applications are
> responsive to congetsion signals (packet drops, ECN..) within a few
> RTTs. If that holds true then the aggregate traffic in a bottleneck
> will not load the network beyond the point where delay gets high (or
> packet losses increases daramatically)
> 
> /Ingemar
> 
> 
> 
> 
> > -----Original Message-----
> > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
> > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com]
> > Sent: den 10 november 2010 15:25
> > To: Mark Watson; Kathy McEwen
> > Cc: Lars Eggert; David Singer; Ingemar Johansson S;
> > httpstreaming; dispatch@ietf.org; conex@ietf.org
> > Subject: RE: [httpstreaming] [dispatch] Q-HTTP
> >
> >
> > 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 [mailto:watsonm@netflix.com] 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;
> > dispatch@ietf.org; conex@ietf.org
> > Asunto: Re: [httpstreaming] [dispatch] Q-HTTP
> >
> >
> >
> > Sent from my iPad
> >
> > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen"
> > <kathy@iridescentnetworks.com> wrote:
> >
> > > One problem with the voice analogy is that the sheer volume of data
> > > traversing the web today is not driven by voice...it'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.
> >
> > ...Mark
> >
> > > -----Original Message-----
> > > From: httpstreaming-bounces@ietf.org
> > > [mailto:httpstreaming-bounces@ietf.org]
> > > On Behalf Of Lars Eggert
> > > Sent: Tuesday, November 09, 2010 8:02 PM
> > > To: David Singer
> > > Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);
> > > httpstreaming; dispatch@ietf.org; conex@ietf.org
> > > 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
> > > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much
> > > the same argument.
> > >
> > > Lars
> > >
> > > _______________________________________________
> > > httpstreaming mailing list
> > > httpstreaming@ietf.org
> > > https://www.ietf.org/mailman/listinfo/httpstreaming
> > >
> >
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex