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

["Ali C. Begen (abegen)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
> <[e-mail]> wrote:
> > Would you please precise which room exactly?
> >
> >>
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Qin Wu <[e-mail]>
> >>> To: [e-mail]
> >>> 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 <[e-mail]>
> >>> To: [e-mail]
> >>> 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 <[e-mail]>
> >>> To: Mark Watson <[e-mail]>
> >>> 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" <[e-mail]>
> >>> To: "Qin Wu" <[e-mail]>
> >>> Cc: <[e-mail]>
> >>> 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) || [e-mail] || phone +49 89
> >>> >> 978980 02 || cell [phone] || 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
> >>> >> [e-mail]
> >>> >> https://www.ietf.org/mailman/listinfo/httpstreaming
> >>> >>
> >>> >
> >>> > _______________________________________________
> >>> > httpstreaming mailing list
> >>> > [e-mail]
> >>> > https://www.ietf.org/mailman/listinfo/httpstreaming
> >>>
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Qin Wu <[e-mail]>
> >>> To: Mark Watson <[e-mail]>, "Severa, Michael J (Mike)"
> >>> <[e-mail]>
> >>> 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" <[e-mail]>
> >>> To: "Severa, Michael J (Mike)" <[e-mail]>
> >>> Cc: "Qin Wu" <[e-mail]>; <[e-mail]>
> >>> 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: [e-mail] [[e-mail]]
> >>> > On Behalf Of Qin Wu [[e-mail]]
> >>> > Sent: Thursday, October 28, 2010 8:02 PM
> >>> > To: Mark Watson; [e-mail]
> >>> > Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New
> >>> > Version Notification for      draft-zong-httpstreaming-gap-analysis-01)
> >>> >
> >>> > Hi,
> >>> > ----- Original Message -----
> >>> > From: "Mark Watson" <[e-mail]>
> >>> > To: <[e-mail]>
> >>> > 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) || [e-mail] || phone +49 89
> >>> >> 978980 02 || cell [phone] || 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
> >>> >> [e-mail]
> >>> >> https://www.ietf.org/mailman/listinfo/httpstreaming
> >>> >>
> >>> >
> >>> > _______________________________________________
> >>> > httpstreaming mailing list
> >>> > [e-mail]
> >>> > https://www.ietf.org/mailman/listinfo/httpstreaming
> >>> > _______________________________________________
> >>> > httpstreaming mailing list
> >>> > [e-mail]
> >>> > https://www.ietf.org/mailman/listinfo/httpstreaming
> >>> >
> >>>
> >>>
> >>> _______________________________________________
> >>> httpstreaming mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/httpstreaming
> >>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > httpstreaming mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/httpstreaming
> >
> >
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming