Re: [httpstreaming] Current Status and Our Goal

Daniel Park <soohongp@gmail.com> Fri, 01 October 2010 02:02 UTC

Return-Path: <soohongp@gmail.com>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354133A6E89 for <httpstreaming@core3.amsl.com>; Thu, 30 Sep 2010 19:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.187
X-Spam-Level:
X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2C+p8y7Sh62 for <httpstreaming@core3.amsl.com>; Thu, 30 Sep 2010 19:02:29 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 509593A6C59 for <httpstreaming@ietf.org>; Thu, 30 Sep 2010 19:02:29 -0700 (PDT)
Received: by iwn3 with SMTP id 3so3841254iwn.31 for <httpstreaming@ietf.org>; Thu, 30 Sep 2010 19:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hCVcw+djbgkxobJOULdYO1UuYSQtZlLEv9Dlj+fUZlo=; b=A5x89WLn1GlBG/+79yJ25OnDWjvDK2JoNJ2v4iuLc5QUsuhinMb6CHbQAs8Ch37uEc 6Upe1JVBZ6jiGEiZerF/COxmqH5ZuLlkT2UgZQljXN9nCrsgzBl6yOacwtsBzi9dk8BM Y7WPhs4kjq9OuTJMXNknMpKziMYSksjiPyAic=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j9cCKSuZIOstUA7tlVat1K1izkEd8psJaCVOkYhBmHUUhZl/QNUv33+vjJC6xYK/nO L8FgjtqnYO03mOIJd9c9D/gAEK08b9fydPAdxqs4Tm+5v1m4e/Yyr+d+fZgLvaltSV/9 CrS3swETMERKL9vDN9zZ9K5/50mii16KF9Adk=
MIME-Version: 1.0
Received: by 10.231.166.139 with SMTP id m11mr4793909iby.136.1285898593850; Thu, 30 Sep 2010 19:03:13 -0700 (PDT)
Received: by 10.231.113.167 with HTTP; Thu, 30 Sep 2010 19:03:13 -0700 (PDT)
In-Reply-To: <C8CA2FC7.5093%luby@qualcomm.com>
References: <18429BFD-5C5F-4513-85B7-8B91F6D28C97@niven-jenkins.co.uk> <C8CA2FC7.5093%luby@qualcomm.com>
Date: Fri, 1 Oct 2010 11:03:13 +0900
Message-ID: <AANLkTi=FjRtAiqAjNob_Uk5um2HwipTMiprkZr+Lvt59@mail.gmail.com>
From: Daniel Park <soohongp@gmail.com>
To: "Luby, Michael" <luby@qualcomm.com>
Content-Type: multipart/alternative; boundary=005045013c64e75a48049184980c
Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>
Subject: Re: [httpstreaming] Current Status and Our Goal
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2010 02:02:31 -0000

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 <luby@qualcomm.com> 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" <ben@niven-jenkins.co.uk> 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
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
>



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