[httpstreaming] Room for Ad-hoc meeting and number of attendees

"David A. Bryan" <dbryan@ethernot.org> Wed, 03 November 2010 15:02 UTC

Return-Path: <davidbryan@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 0C3A43A6AC0 for <httpstreaming@core3.amsl.com>; Wed, 3 Nov 2010 08:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 ztHNifVvXXqZ for <httpstreaming@core3.amsl.com>; Wed, 3 Nov 2010 08:02:47 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9130C3A69B8 for <httpstreaming@ietf.org>; Wed, 3 Nov 2010 08:02:46 -0700 (PDT)
Received: by wwe15 with SMTP id 15so708430wwe.13 for <httpstreaming@ietf.org>; Wed, 03 Nov 2010 08:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zZ+XHZmjj4MM755C00gfXa89htJ78FdOERQaXLTwzSA=; b=xpN/jyCe4rYvOIg9TFwZI6PFdZQb+aOhbAS5gcz2JZeiorRAn3UniA4ML0czei6HAX dFOdmd/DByj2MLGmaNI3PrX78uamOC92RDPWhCgozMIt73FvO5qJfbLHigp4iZwuHEtf zU6RJbcV0FLSqIh+DwLtJAWPhRGaS+NXTAU+Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=xmiOy67ziJKczO2iYwZ8okAL8FwUQNYx4rwT3P1YcZlWsAfW6X5gBluIpnxsBg08JV ZexS8TGve2ClM61eQJf0groMwtOyo/hAraRLZT3YAzxzLuzngXr43X6N0JTGI4kW0j67 hRMJlR1y0brups7C7h5j7vB1b/GncI77kzMLw=
MIME-Version: 1.0
Received: by 10.227.136.72 with SMTP id q8mr15368819wbt.52.1288796572231; Wed, 03 Nov 2010 08:02:52 -0700 (PDT)
Sender: davidbryan@gmail.com
Received: by 10.227.207.195 with HTTP; Wed, 3 Nov 2010 08:02:52 -0700 (PDT)
Date: Wed, 3 Nov 2010 11:02:52 -0400
X-Google-Sender-Auth: nctqxR7mJAcC35bo1C5NrxNlVg0
Message-ID: <AANLkTin0PaG9fwY_CcG=F4Bub_6XfjmmM4_feF=0BEwR@mail.gmail.com>
From: "David A. Bryan" <dbryan@ethernot.org>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: httpstreaming <httpstreaming@ietf.org>, Hasnaa Moustafa <hasnaa.moustafa@gmail.com>
Subject: [httpstreaming] Room for Ad-hoc meeting and number of attendees
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: Wed, 03 Nov 2010 15:02:50 -0000

(just noticed the subject line was not very useful, so changed it...)

Unfortunately, while we are still trying, the answer to both (bigger
room or WebEx) is probably not. Remember this is an informal meeting
-- an ad-hoc group of folks getting together to discuss a concept, and
not an official IETF sanctioned event. Basically, a group of folks
want to talk about HTTP streaming, and *if* there is interest, a clear
direction, and IESG support following that meeting, it might be a
formal BoF at the next meeting. We certainly aren't ready as a group
to have a real BoF yet -- the direction is too unclear -- so this is
really the only sort of meeting we can have.

We have tried to get a bigger room and WebEx, but the overall meeting
is already very full, and support staff aren't always available at the
late hour we have available, so at least so far we haven't been able
to do so (we'll keep trying). Again, Alexey has been able to get us
the IESG room, so that is a great help. In the past, these kind of
meetings would (literally) have been held in a bar or some other
unofficial location, hence the term "bar-BoF" (a bit misleading, since
it is not a BoF by IETF standards). Occasionally (particularly in the
recent past) there have been informal meetings like this that have had
bigger rooms, but that has become increasingly difficult at the last
few meetings as the number of WGs has increased and competition for
rooms has become more fierce.

Also, so far, only 12 people voted in the Doodle Poll
(http://doodle.com/86ifrv5i9i9g7trp), so that gives us some hope we
will have enough room. Maybe folks who are planning to come on Wed.
night and who didn't vote in the poll can go do so now (even though
the time is now fixed) just so we can get a better headcount and see
if this is really likely to be a concern?

David



On Wed, Nov 3, 2010 at 10:22 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> If the room is indeed small, can't we try to get a larger room (e.g., one of the meeting rooms)? Also, will webex be enabled?
>
> -acbegen
>
>> -----Original Message-----
>> From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of David A. Bryan
>> Sent: Wednesday, November 03, 2010 10:13 AM
>> To: Hasnaa Moustafa
>> Cc: httpstreaming
>> Subject: Re: [httpstreaming] httpstreaming Digest, Vol 3, Issue 1
>>
>> The floorplan map available for download on the IETF webpage has no
>> names or labels yet, so not really helpful! We will have to wait until
>> we arrive at the event to get a map.
>>
>> "The IESG Room" is a room assigned to the IESG for their use (and
>> which Alexey has been very helpful in getting for our use). It will
>> have a sign outside that says IESG room, and will proabably be labeled
>> as such on the map you get at registration time. In any case, I can
>> send out that info early in the week once we get to Beijing.
>>
>> Note the room is likely pretty small. These are typically more
>> conference rooms than large session rooms, so it appears it will hold
>> something like 30 people -- arrive early, it will likely be standing
>> room only!
>>
>> David
>>
>> On Wed, Nov 3, 2010 at 8:33 AM, Hasnaa Moustafa
>> <hasnaa.moustafa@gmail.com> wrote:
>> > Would you please precise which room exactly?
>> >
>> >>
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Qin Wu <sunseawq@huawei.com>
>> >>> To: httpstreaming@ietf.org
>> >>> Date: Mon, 01 Nov 2010 09:02:52 +0800
>> >>> Subject: [httpstreaming] Time and location for HTTP streaming bar BoF
>> >>> Hi, experts:
>> >>> We have got one IESG room for our Bar BOF with the AD's kind help. Thank
>> >>> Alex for arranging this for us.
>> >>> As we voted before through Doodle, the Bar BoF is scheduled on
>> >>> Wednesday(10th,Nov) evening
>> >>> from 19:30PM to 21:00PM.
>> >>> If you are interested in this work or would like to contribute, please
>> >>> join our discussion.
>> >>> If you have any other suggestions, please let us know.
>> >>>
>> >>> Regards!
>> >>> -Qin
>> >>>
>> >>>
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Qin Wu <sunseawq@huawei.com>
>> >>> To: httpstreaming@ietf.org
>> >>> Date: Mon, 01 Nov 2010 11:19:58 +0800
>> >>> Subject: [httpstreaming] Meeting Agenda preparation for Bar BOF of HTTP
>> >>> Streaming
>> >>> Hi, Folks:
>> >>> This is just a quick note to let you know that preparations are
>> >>> proceeding for
>> >>> HTTP Streaming Bar BOF meeting.
>> >>> Based on what we have on the table and some suggestions from experts on
>> >>> this list, we think at least three topics should be covered in the meeting
>> >>> agenda:
>> >>> a. Goal and Scope Discussion
>> >>> b. Use Case discussion
>> >>> c. Gap Analysis
>> >>> if you have any questions or comments, please feel free to ping the list.
>> >>> We will soon create meeting agenda based on your feedbacks.
>> >>>
>> >>> Regards!
>> >>> -Qin
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Qin Wu <sunseawq@huawei.com>
>> >>> To: Mark Watson <watsonm@netflix.com>
>> >>> Date: Mon, 01 Nov 2010 15:54:27 +0800
>> >>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> >>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> >>> Hi,
>> >>> ----- Original Message -----
>> >>> From: "Mark Watson" <watsonm@netflix.com>
>> >>> To: "Qin Wu" <sunseawq@huawei.com>
>> >>> Cc: <httpstreaming@ietf.org>
>> >>> Sent: Friday, October 29, 2010 12:30 PM
>> >>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> >>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> >>>
>> >>>
>> >>>
>> >>> On Oct 28, 2010, at 8:02 PM, Qin Wu wrote:
>> >>> >
>> >>> > [Qin]: Sounds like a good idea to me. I think this is one way to build
>> >>> > the interoperable solution for concurrent live streaming viewing with
>> >>> > backwards compability to existing cache and client, which may bring the
>> >>> > advantage of alleviating server load.  But I am not sure the MIME subtype
>> >>> > has the right semantic to do this.
>> >>>
>> >>> [MW] Can you elaborate ?
>> >>>
>> >>> [Qin]: That's what I intepret from what you propose for efficient
>> >>> manifest delivery.
>> >>> As you said, we may need to define new MIME type for manifest push, I
>> >>> agree.
>> >>> Futhermore, I think it will be a good idea to use such feature also for
>> >>> media stream efficient delivery when
>> >>> concurrent streams needs to be served by the same web server and the old
>> >>> chunk that has been playout and in aging conditions
>> >>> need to be dropped.
>> >>>
>> >>> The idea would be if the smart cache in between knows the semantics of
>> >>> new MIME type, this smart
>> >>> caches can choose to replace/update the previous chunk with the new chunk
>> >>> and
>> >>> only serve the newest chunk to all the concurrent live streaming viewers.
>> >>>
>> >>> For details, we may discuss this in Beijing meeting.
>> >>>
>> >>> > We may need some new MIME subtype and new behaviors on how to process
>> >>> > it.
>> >>> >
>> >>> > ...Mark
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote:
>> >>> >
>> >>> >> Ning,
>> >>> >>
>> >>> >> thanks ....
>> >>> >>
>> >>> >> I recognized that you only replied to some of my comments.
>> >>> >> Does this mean that you agree/disagree with the remaining ones?
>> >>> >>
>> >>> >> Inline some more with [T] ... [\T]
>> >>> >>
>> >>> >> Thomas
>> >>> >>
>> >>> >>> - I am not sure I understand the term "is encrypted into files"
>> >>> >>> [ZN]: I mean "use file with media container" here.
>> >>> >>
>> >>> >> [T]  I do not understand this either! [\T]
>> >>> >>
>> >>> >>> - What do you mean "normal text file"?
>> >>> >>> [ZN]: traditional web page (e.g. html file).
>> >>> >>
>> >>> >> [T] we should be much more careful with terminology [\T]
>> >>> >>
>> >>> >>> - The intelligence in the Adaptive Streaming over HTTP is almost
>> >>> >>> exclusively in the client, there is no negotiation
>> >>> >>> [ZN]: Sorry for confusion, "negotiation" should be "massage
>> >>> >>> exchange".
>> >>> >>
>> >>> >> [T]
>> >>> >> First I hope this is a typo, otherwise I get more curious ...!
>> >>> >> Secondly, I am still not clear what needs to be done beyond regular
>> >>> >> http connections
>> >>> >> [\T]
>> >>> >>
>> >>> >>> 5.2)
>> >>> >>> - It is not correct that the 3GPP MPD needs to be updated even for
>> >>> >>> live. If you use a template mode, the MPD stays static until some
>> >>> >>> "unforeseen" event occurs. Client and Content Preparation have agreed
>> >>> >>> on rules to construct URIs.
>> >>> >>> - If necessary, the MPD update happens asynchronously to the media
>> >>> >>> decoding, so this is not considered to be a problem.
>> >>> >>> [ZN]: I didn't intend to state that pull model doesn't work. My
>> >>> >>> point is,
>> >>> >>> why not investigating the possible usage of push model in certain
>> >>> >>> cases
>> >>> >>> without experiencing the above mentioned "unforeseen" event or
>> >>> >>> asynchronous
>> >>> >>> updates?
>> >>> >>
>> >>> >> [T]
>> >>> >> "Push" is a very very broad term. In Web applications you can for
>> >>> >> example use AJAX or RSS/ATOM like techniques for push-like updates. If
>> >>> >> you use conditional GET for regular polling, this is very efficient.
>> >>> >> The MPD updates in 3GPP work in a similar manner. If you use polling,
>> >>> >> conditional GETs and templates, you are extremely efficient. We should
>> >>> >> really understand what we mean by push model? HTTP-based delivery is
>> >>> >> rich and provides many successfully deployed options.
>> >>> >>
>> >>> >> Should you really refer to something completely different such as IP
>> >>> >> multicast, then I would feel very very uncomfortable.
>> >>> >> [\T]
>> >>> >>
>> >>> >>> - There is for sure mechanisms to deliver important packets more
>> >>> >>> reliably in HTTP - you just request it earlier. In anticipation of
>> >>> >>> switching a smart client may also prepare such data. The client is
>> >>> >>> intelligent.
>> >>> >>> [ZN]: Well, I think this startup issue doesn't like the pre-fetch
>> >>> >>> which is
>> >>> >>> of course still valuable to improve playback. IMO, it is hard to
>> >>> >>> predict
>> >>> >>> which channel the user will switch to in the next moment, hence it
>> >>> >>> is not
>> >>> >>> reasonable to request important packets for other channels. Did I
>> >>> >>> misunderstand you?
>> >>> >>
>> >>> >> [T]
>> >>> >> I would not be worried to have the MPD and the initialization segment
>> >>> >> of the two neighboring channels ready in my device. Again, the client
>> >>> >> can be very smart, especially as it does have access to all the
>> >>> >> information.
>> >>> >>
>> >>> >> In general, I do not disagree that we can create more detailed use
>> >>> >> cases for environments in which we envision that HTTP streaming will
>> >>> >> be used. This may include live multi-channel environments. However, we
>> >>> >> should not conclude per se that the existing technologies do have a
>> >>> >> problem.
>> >>> >> [\T]
>> >>> >>
>> >>> >>> - 3GPP defines QoE metrics that can reused also for HTTP Streaming.
>> >>> >>> there will also be efforts in MPEG in including QoE.
>> >>> >>> [ZN]: I am not proposing to focus on defining QoE metrics, but
>> >>> >>> looking on
>> >>> >>> the protocols to report such metrics, like RTCP. We will support the
>> >>> >>> work in
>> >>> >>> 3GPP/MPEG and cooperate with them to see how to capsulate the
>> >>> >>> metrics in a
>> >>> >>> series of messages.
>> >>> >>
>> >>> >> [T]
>> >>> >> What do you mean with "capsulate"?
>> >>> >> Also, can you be more specific what metrics there are in RTCP that can
>> >>> >> also be used in HTTP Streaming. I consider that anything dealing with
>> >>> >> packet loss is irrelevant. I also do not see the relevance of sending
>> >>> >> regular 5 seconds receiver reports as the content is static and
>> >>> >> adaptation will not happen. Some reporting on Media Presentation level
>> >>> >> may be sufficient, for example when the presentation has been
>> >>> >> completed.
>> >>> >> [\T]
>> >>> >>
>> >>> >>
>> >>> >> ---
>> >>> >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89
>> >>> >> 978980 02 || cell +491725702667 || http://www.nomor-research.com
>> >>> >> Nomor Research GmbH  -  Sitz der Gesellschaft: München -
>> >>> >> Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 -
>> >>> >> Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> httpstreaming mailing list
>> >>> >> httpstreaming@ietf.org
>> >>> >> https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>> >>
>> >>> >
>> >>> > _______________________________________________
>> >>> > httpstreaming mailing list
>> >>> > httpstreaming@ietf.org
>> >>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>>
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Qin Wu <sunseawq@huawei.com>
>> >>> To: Mark Watson <watsonm@netflix.com>om>, "Severa, Michael J (Mike)"
>> >>> <mike.severa@alcatel-lucent.com>
>> >>> Date: Mon, 01 Nov 2010 16:51:45 +0800
>> >>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> >>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> >>> Hi,
>> >>> ----- Original Message -----
>> >>> From: "Mark Watson" <watsonm@netflix.com>
>> >>> To: "Severa, Michael J (Mike)" <mike.severa@alcatel-lucent.com>
>> >>> Cc: "Qin Wu" <sunseawq@huawei.com>om>; <httpstreaming@ietf.org>
>> >>> Sent: Friday, October 29, 2010 12:32 PM
>> >>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> >>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> >>>
>> >>>
>> >>> Server-sent events defines a stream format for a sequence of DOM events.
>> >>> Essentially each is a set of name/value pairs. It's a very simple text
>> >>> syntax. Not really suitable for manifest updates or video stream segments.
>> >>> But mainly it does not carry any semantics that would enable cache
>> >>> optimizations.
>> >>>
>> >>> [Qin]: I think it is possible to use server-sent event over HTTP or using
>> >>> dedicated server-push protocol to push text based manifest or some metadata
>> >>> for current playlist to the client since the manifest can be in different
>> >>> format.
>> >>> But it is true, server push event has no semantics to carry video
>> >>> streaming segments, since video streaming segement is binary data rather
>> >>> than textual data.
>> >>>
>> >>> ...Mark
>> >>>
>> >>> On Oct 28, 2010, at 8:56 PM, Severa, Michael J (Mike) wrote:
>> >>>
>> >>> > Hi. Check out server-sent events in HTML5. Essentially what is
>> >>> > described here, though intended more for the application layer than the
>> >>> > media layer. With a decoder interface at the application layer it would
>> >>> > probably be possible to do this now by using that feature.
>> >>> >
>> >>> > Mike
>> >>> > ________________________________________
>> >>> > From: httpstreaming-bounces@ietf.org [httpstreaming-bounces@ietf.org]
>> >>> > On Behalf Of Qin Wu [sunseawq@huawei.com]
>> >>> > Sent: Thursday, October 28, 2010 8:02 PM
>> >>> > To: Mark Watson; httpstreaming@ietf.org
>> >>> > Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New
>> >>> > Version Notification for      draft-zong-httpstreaming-gap-analysis-01)
>> >>> >
>> >>> > Hi,
>> >>> > ----- Original Message -----
>> >>> > From: "Mark Watson" <watsonm@netflix.com>
>> >>> > To: <httpstreaming@ietf.org>
>> >>> > Sent: Friday, October 29, 2010 3:17 AM
>> >>> > Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> >>> > Notification for draft-zong-httpstreaming-gap-analysis-01)
>> >>> >
>> >>> >
>> >>> > Here is an idea sparked by Thomas' mention below of AJAX and RSS push
>> >>> > services.
>> >>> >
>> >>> > In these services the client establishes a long-lived HTTP connection
>> >>> > to a server on which it sends a single request. The response comes back in
>> >>> > chunks, over time, enabling the server to "push" new content as it becomes
>> >>> > available. Generally caches and proxies are transparent to this, although I
>> >>> > think it does not work with some older proxies which expect to receive the
>> >>> > whole response from upstream before returning anything to the client.
>> >>> > Perhaps these are all gone by now. But anyway, the "chunks" cannot really be
>> >>> > cached as the proxy has no idea what they are.
>> >>> >
>> >>> > In the case of a document, such as a manifest, which is being
>> >>> > periodically updated, or a sequence of different files, one could very
>> >>> > simply expose these semantics in a standard way, which would enable caches
>> >>> > to do their thing.
>> >>> >
>> >>> > For example, suppose we define a new MIME type, multipart/versions,
>> >>> > where each part of the multipart MIME response is a different version of the
>> >>> > originally requested resource. A smart cache receiving a request for this
>> >>> > resource can cache the "parts" as they arrive, each replacing the previously
>> >>> > cached version. It can serve multiple incoming persistent connections with
>> >>> > one upstream persistent connection, providing scalability. It would be
>> >>> > transparent to existing caches. Clients would indicate their support in the
>> >>> > Accept header and clients which did not support this mode would just poll
>> >>> > the resource in the usual way with conditional GET requests.
>> >>> >
>> >>> > All that would be required from a standards perspective would be
>> >>> > definition of the multipart/versions MIME type.
>> >>> >
>> >>> > Maybe this is not new. I could easily imagine CDNs do this kind of
>> >>> > thing internally already.
>> >>> >
>> >>> > Similarly, one could imagine a multipart/sequence MIME type where the
>> >>> > parts form a sequence of objects. The client requests an object and (if it
>> >>> > indicates support of the multipart/sequence MIME type) gets back that object
>> >>> > and subsequent ones in the sequence (with their file names). Again, smart
>> >>> > caches could optimise for scalability, caching the parts as separate
>> >>> > objects. This could help with delivery of segments in the live case, but
>> >>> > again maintaining backwards-compatibility. Again, perhaps CDNs already do
>> >>> > something like this internally.
>> >>> >
>> >>> > I'm not proposing to progress these ideas, just thought they were
>> >>> > interesting.
>> >>> >
>> >>> > [Qin]: Sounds like a good idea to me. I think this is one way to build
>> >>> > the interoperable solution for concurrent live streaming viewing with
>> >>> > backwards compability to existing cache and client, which may bring the
>> >>> > advantage of alleviating server load.  But I am not sure the MIME subtype
>> >>> > has the right semantic to do this. We may need some new MIME subtype and new
>> >>> > behaviors on how to process it.
>> >>> >
>> >>> > ...Mark
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote:
>> >>> >
>> >>> >> Ning,
>> >>> >>
>> >>> >> thanks ....
>> >>> >>
>> >>> >> I recognized that you only replied to some of my comments.
>> >>> >> Does this mean that you agree/disagree with the remaining ones?
>> >>> >>
>> >>> >> Inline some more with [T] ... [\T]
>> >>> >>
>> >>> >> Thomas
>> >>> >>
>> >>> >>> - I am not sure I understand the term "is encrypted into files"
>> >>> >>> [ZN]: I mean "use file with media container" here.
>> >>> >>
>> >>> >> [T]  I do not understand this either! [\T]
>> >>> >>
>> >>> >>> - What do you mean "normal text file"?
>> >>> >>> [ZN]: traditional web page (e.g. html file).
>> >>> >>
>> >>> >> [T] we should be much more careful with terminology [\T]
>> >>> >>
>> >>> >>> - The intelligence in the Adaptive Streaming over HTTP is almost
>> >>> >>> exclusively in the client, there is no negotiation
>> >>> >>> [ZN]: Sorry for confusion, "negotiation" should be "massage
>> >>> >>> exchange".
>> >>> >>
>> >>> >> [T]
>> >>> >> First I hope this is a typo, otherwise I get more curious ...!
>> >>> >> Secondly, I am still not clear what needs to be done beyond regular
>> >>> >> http connections
>> >>> >> [\T]
>> >>> >>
>> >>> >>> 5.2)
>> >>> >>> - It is not correct that the 3GPP MPD needs to be updated even for
>> >>> >>> live. If you use a template mode, the MPD stays static until some
>> >>> >>> "unforeseen" event occurs. Client and Content Preparation have agreed
>> >>> >>> on rules to construct URIs.
>> >>> >>> - If necessary, the MPD update happens asynchronously to the media
>> >>> >>> decoding, so this is not considered to be a problem.
>> >>> >>> [ZN]: I didn't intend to state that pull model doesn't work. My
>> >>> >>> point is,
>> >>> >>> why not investigating the possible usage of push model in certain
>> >>> >>> cases
>> >>> >>> without experiencing the above mentioned "unforeseen" event or
>> >>> >>> asynchronous
>> >>> >>> updates?
>> >>> >>
>> >>> >> [T]
>> >>> >> "Push" is a very very broad term. In Web applications you can for
>> >>> >> example use AJAX or RSS/ATOM like techniques for push-like updates. If
>> >>> >> you use conditional GET for regular polling, this is very efficient.
>> >>> >> The MPD updates in 3GPP work in a similar manner. If you use polling,
>> >>> >> conditional GETs and templates, you are extremely efficient. We should
>> >>> >> really understand what we mean by push model? HTTP-based delivery is
>> >>> >> rich and provides many successfully deployed options.
>> >>> >>
>> >>> >> Should you really refer to something completely different such as IP
>> >>> >> multicast, then I would feel very very uncomfortable.
>> >>> >> [\T]
>> >>> >>
>> >>> >>> - There is for sure mechanisms to deliver important packets more
>> >>> >>> reliably in HTTP - you just request it earlier. In anticipation of
>> >>> >>> switching a smart client may also prepare such data. The client is
>> >>> >>> intelligent.
>> >>> >>> [ZN]: Well, I think this startup issue doesn't like the pre-fetch
>> >>> >>> which is
>> >>> >>> of course still valuable to improve playback. IMO, it is hard to
>> >>> >>> predict
>> >>> >>> which channel the user will switch to in the next moment, hence it
>> >>> >>> is not
>> >>> >>> reasonable to request important packets for other channels. Did I
>> >>> >>> misunderstand you?
>> >>> >>
>> >>> >> [T]
>> >>> >> I would not be worried to have the MPD and the initialization segment
>> >>> >> of the two neighboring channels ready in my device. Again, the client
>> >>> >> can be very smart, especially as it does have access to all the
>> >>> >> information.
>> >>> >>
>> >>> >> In general, I do not disagree that we can create more detailed use
>> >>> >> cases for environments in which we envision that HTTP streaming will
>> >>> >> be used. This may include live multi-channel environments. However, we
>> >>> >> should not conclude per se that the existing technologies do have a
>> >>> >> problem.
>> >>> >> [\T]
>> >>> >>
>> >>> >>> - 3GPP defines QoE metrics that can reused also for HTTP Streaming.
>> >>> >>> there will also be efforts in MPEG in including QoE.
>> >>> >>> [ZN]: I am not proposing to focus on defining QoE metrics, but
>> >>> >>> looking on
>> >>> >>> the protocols to report such metrics, like RTCP. We will support the
>> >>> >>> work in
>> >>> >>> 3GPP/MPEG and cooperate with them to see how to capsulate the
>> >>> >>> metrics in a
>> >>> >>> series of messages.
>> >>> >>
>> >>> >> [T]
>> >>> >> What do you mean with "capsulate"?
>> >>> >> Also, can you be more specific what metrics there are in RTCP that can
>> >>> >> also be used in HTTP Streaming. I consider that anything dealing with
>> >>> >> packet loss is irrelevant. I also do not see the relevance of sending
>> >>> >> regular 5 seconds receiver reports as the content is static and
>> >>> >> adaptation will not happen. Some reporting on Media Presentation level
>> >>> >> may be sufficient, for example when the presentation has been
>> >>> >> completed.
>> >>> >> [\T]
>> >>> >>
>> >>> >>
>> >>> >> ---
>> >>> >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89
>> >>> >> 978980 02 || cell +491725702667 || http://www.nomor-research.com
>> >>> >> Nomor Research GmbH  -  Sitz der Gesellschaft: München -
>> >>> >> Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 -
>> >>> >> Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> httpstreaming mailing list
>> >>> >> httpstreaming@ietf.org
>> >>> >> https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>> >>
>> >>> >
>> >>> > _______________________________________________
>> >>> > httpstreaming mailing list
>> >>> > httpstreaming@ietf.org
>> >>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>> > _______________________________________________
>> >>> > httpstreaming mailing list
>> >>> > httpstreaming@ietf.org
>> >>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>> >
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> httpstreaming mailing list
>> >>> httpstreaming@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>>
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > httpstreaming mailing list
>> > httpstreaming@ietf.org
>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>> >
>> >
>> _______________________________________________
>> httpstreaming mailing list
>> httpstreaming@ietf.org
>> https://www.ietf.org/mailman/listinfo/httpstreaming
>