Re: [httpstreaming] httpstreaming Digest, Vol 3, Issue 1

"Ali C. Begen (abegen)" <abegen@cisco.com> Wed, 03 November 2010 14:23 UTC

Return-Path: <abegen@cisco.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 B0DE13A6ABD for <httpstreaming@core3.amsl.com>; Wed, 3 Nov 2010 07:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 9Dt5PIOdoW04 for <httpstreaming@core3.amsl.com>; Wed, 3 Nov 2010 07:23:16 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 544713A69C0 for <httpstreaming@ietf.org>; Wed, 3 Nov 2010 07:23:16 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKsM0UyrR7H+/2dsb2JhbAChZHGiYZtfAoVEBIRXiQyCZw
X-IronPort-AV: E=Sophos;i="4.58,289,1286150400"; d="scan'208";a="280269846"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 Nov 2010 14:23:23 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA3ENNNf006444; Wed, 3 Nov 2010 14:23:23 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Nov 2010 07:23:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Nov 2010 07:22:57 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D8EAA05@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <AANLkTinE+EVVauOrtSJ=PN16WGRf+qt+JFkSXGyHm0SK@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [httpstreaming] httpstreaming Digest, Vol 3, Issue 1
Thread-Index: Act7YU4kzwclOYA0QmquaTZPJk4wEwAATHBw
References: <mailman.17.1288601518.4822.httpstreaming@ietf.org><AANLkTin1NK+te=KGWVawfJxjzNVgdO2PdoQ9jB60jZqC@mail.gmail.com><AANLkTimN9MKMqbnB_u9jpDTF=q3xXiHEYaWsHy4-AAkj@mail.gmail.com><AANLkTimaM6ULdmgSwexSdQwtz=evJcakfL97U-cbnBnp@mail.gmail.com> <AANLkTinE+EVVauOrtSJ=PN16WGRf+qt+JFkSXGyHm0SK@mail.gmail.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "David A. Bryan" <dbryan@ethernot.org>, "Hasnaa Moustafa" <hasnaa.moustafa@gmail.com>
X-OriginalArrivalTime: 03 Nov 2010 14:23:23.0102 (UTC) FILETIME=[ABE38FE0:01CB7B62]
Cc: httpstreaming <httpstreaming@ietf.org>
Subject: Re: [httpstreaming] httpstreaming Digest, Vol 3, Issue 1
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 14:23:18 -0000

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