Re: [httpstreaming] Current Status and Our Goal

[Daniel Park <[e-mail]>]

That's what I pointed out at the previous mail.

"gap analysis among the existing approaches"

For example, a new design team (or study team) can be formed together in
this group. It's very general process within IETF to harmonize different
voices.


Daniel @ Samsung


On Fri, Oct 1, 2010 at 4:15 AM, Luby, Michael <[e-mail]> wrote:

> One thing I suggest is that this group seriously study DASH standardization
> work in 3GPP and MPEG to understand what these standards do and do not
> address, preferably before deciding whether or not to start a group and
> definitely before establishing a charter if the decision is to start a
> group.
>
>
> On 9/30/10 10:13 AM, "Ben Niven-Jenkins" <[e-mail]> wrote:
>
> > David, Colleagues,
> >
> > On 29 Sep 2010, at 19:59, David A. Bryan wrote:
> >
> >> So we have had a number of threads, some about possible work, some
> >> about details in the charter, etc. I think it is great to start
> >> thinking about a possible charter if this work turns into a WG, and
> >> some good reference drafts (thanks to Qin and the folks from Apple for
> >> putting these together), but I think another way to look at this might
> >> be to at least initially take a step back and see if the folks on the
> >> list can take a stab at some more basic questions. I think that was
> >> perhaps what Qin was getting at when we started this thread, but it is
> >> always good to refocus.
> >>
> >
> > Ah! I (wrongly) assumed that the areas of possible work were already
> known to
> > someone and the proposed charter was just an attempt to articulate them.
> >
> >> I'll ask two really basic questions to the folks on list, and let's
> >> see what the opinions may be, and maybe we can move forward from
> >> there. Personally, I think that if we have a bar BoF, focusing just on
> >> these two basic questions (ok, one is a compound question, but one is
> >> basic!) might be a good way to move forward. I expect we'll have some
> >> VERY different answers. Remember that HTTP streaming may mean
> >> different things to people, and might even be the wrong term...but
> >> these are the things we need to try to figure out.
> >>
> >> So the two big questions:
> >>
> >> 1) On the topic of this list/HTTP streaming, what do you think is the
> >> problem/problems/scenario we should be looking at?
> >>
> >
> > I do not feel I am in a position just yet to start making statements
> about
> > what problems I think a HTTP streaming group (if formed) should look at,
> > however one area that I think may be interesting to study and that I am
> not
> > aware of other bodies looking at is "chunk hints".
> >
> > A lot of streaming media today is delivered via CDNs that operate as more
> than
> > just a dumb (inline) proxy cache.
> >
> > HTTP naturally supports the insertion of caches transparently to the end
> > points so one could argue that nothing more needs to be done for HTTP
> > streaming than for regular HTTP.
> >
> > As adaptive bit rate combined with HTTP delivery relies on throughput
> > measurements to determine the appropriate bit rate to download for
> subsequent
> > chunks, variation in latency (e.g. the difference between a request for a
> > chunk being a cache hit Vs a cache miss) is likely to affect the
> throughput
> > perceived by the client and therefore may cause bit rate switch on a
> cache
> > miss that wouldn't have occurred had the request actually been a cache
> hit.
> >
> > If there was some way to provide a "hint" to the server/cache as to which
> > chunk the client is likely to request next then a CDN could elect to
> retrieve
> > that chunk ahead of it actually being requested to keep the response
> latency
> > (or some other factor) more consistent and avoid additional bit rate
> switches.
> >
> >
> >
> >> 2) What other standards body work in this space are you aware of
> >> (including IETF work), and how do you think any new work would fit in
> >> (or not!) with the answer above?
> >
> > None that I am aware of.
> >
> >
> >
>
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>



-- 
Soohong Daniel Park
Samsung Electronics, DMC R&D
http://www.soohongp.com, twitter:@natpt