Re: [httpstreaming] Agenda and Slides

["Ali C. Begen (abegen)" <[e-mail]>]

Can 2g provide acceptable video quality anyway even if everything is close to be perfect? During such a handoff, many things will probably fail to work... it certainly won't be that seamless to the client.

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Kathy McEwen
> Sent: Thursday, November 11, 2010 8:32 AM
> To: Dave Oran (oran)
> Cc: httpstreaming
> Subject: Re: [httpstreaming] Agenda and Slides
> 
> How about the mobile handoff scenario from 3G to 2g where the 2g has only ATM backhaul from the radio, no TCP
> interaction.  .... How does the network and the handset use adaptive rate encoding, http and tcp then?
> 
> Sent from my iPhone
> 
> On Nov 10, 2010, at 7:52 AM, David R Oran <[e-mail]> wrote:
> 
> >
> > On Nov 10, 2010, at 12:13 AM, Xiangsong Cui wrote:
> >
> >> Hi,
> >>
> >> I agree Kathy here.
> >> And, Mark, yes, you are right, it drops packets. But this is only a passive reaction, I think it is better to achieve some active
> operation, or proactive operation (if possible), that would be perfact.
> >>
> > Why? This is not at all obvious to some of us, unless by "proactive" you mean turning on existing machinery that is not yet
> universally deployed, like RED and ECN. There is at least some evidence that currently measured poor adaptive streaming
> behaviors can be explained by tail-drop routers hanging around all over the place. TCP is known to behave badly under heavy
> load with tail-drop queuing. I think you'd agree that it's a whole lot easier to turn on  well understood, standardized and
> nearly universally implemented techniques at the network layer than it it is stumble around trying to invent new application
> and HTTP machinery to try to fake it out.
> >
> > We also don't fully understand the effect of allowing adaptive streaming clients to compete only against each other with no
> cross traffic present to inject enough noise to drive the adaptation algorithms. The deployments today are without putting
> the traffic in a separate QoS class since they run over-the-top on BE service. It is far from clear that removing the cross-
> traffic induced bandwidth variation will make things better - it might, counter-intuitively, make things worse!
> >
> >> I think these jobs are worthy our attention.
> >>
> > I do not think the case has yet been made, although I think you'll find we're all open minded and willing to listen.
> >
> > With respect to the mobile environment specifically, there is an obvious space/time/computation/bandwidth tradeoff with
> respect to multi-rate coding (upon which adaptive HTTP streaming depends). If you only have a few rates to play with, it's
> obviously hard to to optimal bandwidth packing on radio channels that don't support enough users to satisfy the "law of large
> numbers". It's even harder to do it with good fairness properties. There are many ways to skin this cat though:
> >
> > - spend the cycles on the encoders and space in the caches to have finer rate quantization in the multi-rate coding.
> > - match the encoding rates to to the radio channel allocation chunks
> > - transrate a higher rate down to fit in the allocation for a given mobile user if that would result in better QoE than shifting
> them down to the next lower rate.
> >
> > However, I'd like to observe that NONE of these techniques has much (or at least very little) to do with the protocols and
> algorithms for adaptive HTTP streaming.
> >
> > There may be some small tweaks that one might do though. For example, there might be useful transrating hints in server
> manifests to tell streaming servers whether they are permitted to transrate a given profile, and hints in client manifests to
> allow them to request a transrate down as opposed to shifting to the next lower coding rate. Alternatively, the manifests
> could just lie about the number of profiles, and allow servers to "synthesize" the intermediate profiles by transrating.
> >
> > As a parting homily to those who think reservations and admission control are always superior to adaptation in their ability
> to deliver QoE, remember that:
> >
> > "The purpose of bandwidth reservation and admission control is to say NO, not to say YES". If you can always say YES, you
> don't need it, and if you say NO a lot, you are just quantizing unfairness into a boolean."
> >
> > DaveO.
> >
> >
> >
> >
> >> Best Regards
> >> Xiangsong
> >>
> >>
> >> ----- 原邮件 -----
> >> 发件人: Mark Watson <[e-mail]>
> >> 日期: 星期三, 十一月 10日, 2010 下午12:24
> >> 主题: Re: [httpstreaming] Agenda and Slides
> >> 收件人: Kathy McEwen <[e-mail]>
> >> 抄送: httpstreaming <[e-mail]>
> >>
> >>>
> >>>
> >>> Sent from my iPad
> >>>
> >>> On Nov 9, 2010, at 7:42 PM, "Kathy McEwen"
> >>> <[e-mail]> wrote:
> >>>
> >>>> After doing some digging on the various
> >>>> protocols (RTMP/http, RTSP, HTML5/http, etc... ), we found that
> >>> all of them
> >>>> that are doing any kind of adaptive rate streaming, but they do
> >>> not today
> >>>> incorporate the messages/control mechanisms to allow for the
> >>> network to take
> >>>> control and adapt the rate of the video.
> >>>
> >>> But it does! It drops packets, causing a congestion response from
> >>> TCP causing in turn an adaptation by the application. The network
> >>> is completely in control of the packet delivery rate, which the
> >>> application knows and adapts to.
> >>>
> >>> This is the baseline, which is so simple and applicable across
> >>> myriad access technologies. New mechanisms need to justify
> >>> themselves against this baseline.
> >>>
> >>> ...Mark
> >>> _______________________________________________
> >>> httpstreaming mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/httpstreaming
> >>>
> >> <c00111037.vcf>_______________________________________________
> >> httpstreaming mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/httpstreaming
> >
> > _______________________________________________
> > httpstreaming mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/httpstreaming
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming