Re: [httpstreaming] Current Status and Our Goal

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] 
Sent: Wednesday, October 20, 2010 8:42 PM
To: Ning Zong; Roni Even; David A. Bryan; Qin Wu
Cc: httpstreaming@ietf.org
Subject: RE: [httpstreaming] Current Status and Our Goal

> -----Original Message-----
> From: Ning Zong [mailto:zongning@huawei.com]
> Sent: Wednesday, October 20, 2010 3:19 PM
> To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu'
> Cc: httpstreaming@ietf.org
> Subject: RE: [httpstreaming] Current Status and Our Goal
> 
> 
> 
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
> Sent: Wednesday, October 20, 2010 7:22 PM
> To: Ning Zong; Roni Even; David A. Bryan; Qin Wu
> Cc: httpstreaming@ietf.org
> Subject: RE: [httpstreaming] Current Status and Our Goal
> 
> When the traffic is unicast, you don't have the problems we have in a
> multicast environment. The unicast traffic will naturally start from a
> random access point.
> [ZN]: I am a little bit confused by the word "naturally". Do you mean the
> unicast server will adjust the timing such that the starting
packet/segment
> will always begin with RAP? In fact, not all the HTTP streaming system
> mandates that the segmentation should align with RAP.

Then, that's a pretty poor segmentation or the client simply downloads data
that it will discard. The point is the connection is unicast so the client
gets what it needs.

>  You might need some initialization data to start decoding or whatever,
but
> all that comes from the server over unicast anyway.
> [ZN]: right, but the reference information is not always available to be
> transmitted at any time point even using unicast, unless there is a cache
> point.

? That reference information is part of the data the client gets. A cache
cannot produce that data by itself, it needs to see it from upstream, which
means it previously came from the origin server. 
[ZN]: I agree that the RI is part of the data acquired by the client, but
the point is - if every segment carries all the necessary RI? I guess no. So
I am just wondering if there is space to reduce the startup delay in client
side.

My point is that the ret. server we had in RAMS is not needed here since all
the servers that can serve the client is one such entity here. They provide
what the client wants, and if they don't have it, they redirect the client
or fetch it for the client.
[ZN]: The last sentence implies some architecture concerns, and
interesting...

-acbegen

> The same applies to both on-demand and live content.
> 
> -acbegen
> 
> > -----Original Message-----
> > From: Ning Zong [mailto:zongning@huawei.com]
> > Sent: Wednesday, October 20, 2010 11:50 AM
> > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu'
> > Cc: httpstreaming@ietf.org
> > Subject: RE: [httpstreaming] Current Status and Our Goal
> >
> > IMO, the issue may not only related to multicast or unicast, but the QoE
> > improvement (e.g. reduce the startup time after user change the
channel).
> If
> > I remember correctly, in the motivation of FCC in AVT, one important
> concern
> > is that the Retransmission server can store the most recent GoPs and
feed
> > them to the client with faster rate than playback to effectively fill
the
> > gap between the time point of user channel zapping and next complete
GoP.
> > This improvement also applies to unicast based HTTP streaming, right?
> > The above concern also implies that adding some intelligence to
> > intermediaries would improve the streaming performance of HTTP streaming
> > system. To be more specific, having a deep look at the mechanisms of
> > distinguish different types of HTTP traffic (e.g. live streaming with
> higher
> > timing requirement v.s. normal packet, streaming packet containing
I-frame
> > worthy of caching for further usage v.s. normal streaming packet) would
be
> a
> > possible direction for consideration in this list.
> >
> > My two cents.
> >
> > BR,
> > Ning Zong
> >
> > -----Original Message-----
> > From: httpstreaming-bounces@ietf.org
> [mailto:httpstreaming-bounces@ietf.org]
> > On Behalf Of Ali C. Begen (abegen)
> > Sent: Thursday, October 07, 2010 6:15 AM
> > To: Roni Even; David A. Bryan; Qin Wu
> > Cc: httpstreaming@ietf.org
> > Subject: Re: [httpstreaming] Current Status and Our Goal
> >
> > > 2. Address the startup issue, we have worked in AVT on fast
> > channel/content
> > > change and I think this is relevant also in this case.
> >
> > Are you assuming a multicast environment for http streaming? Ow, the
> startup
> > issue is not an issue in unicast connections.
> >
> > -acbegen
> > _______________________________________________
> > httpstreaming mailing list
> > httpstreaming@ietf.org
> > https://www.ietf.org/mailman/listinfo/httpstreaming