Subject: [httpstreaming] Raw notes

From: "David A. Bryan" <[email-masked]>
Date: Thu, 11 Nov 2010 22:52:08 +0800

The raw notes from the ad-hoc yesterday are attached. I'll post them
online as well shortly.

David

---

IETF79 Beijing Nov 2010
HTTP Streaming BarBof, Wednesday November 10th, 19:30-21:00
About 60 Participants

Chairs:
David A Bryan, Yin Wu
Minutes by Christian Schmidt

Yin Wu Presentation: Goals and Scope Discussion

Why is HTTP streaming a popular topic?
Magnus Westerlund:
Two main benefits of HTTP are missing:
*       It works through NAT
*       And it is cost effective.

Why do you need this in HTTP not in the application?
 It should not have influence to Web browser.
Steward Cheshire: Nothing to do with the web-browser, it is about the
network. It is application issue.

Markus Isomaki: What will Browser do today for current streaming solutions?
Steward Cheshire:  Current solutions do not work very well. No matter,
if Video, Audio or something else. Some say use UDP, not use HTTP for
this. This cannot be done for real live communication. For near live
streaming this is sufficient, unless used for sports playback
purposes.

What problem we need to look at:
-       Inefficient Streaming Content Delivery
o       Cullen Perkins: How many of these are implementation and how
many are protocol issues.
o       Yin Wu: First point is protocol issue.
o       Jörg Ott: How big are your chunks, the segments you are
downloading. If the packets are big, the header size is not real an
issue.
o       2 to 10 seconds of the video you want to provide.
o       That is reasonably big.
o       How many of these issues are academic or real issues. Can some
experienced people give information about?
o       Steward Cheshire:  In Appstore, this is the only way to watch
life video on the I-Phone. This is a concession to the mobile
operator.
o       That was not my question. Which issues on this slide is seen
as real issue in the real world.
o       Steward Cheshire:  You are right. I am not aware of any real
problem in this area.
o       Netflex/Mark: He felt there are problems, but different from
the problems reflected here. We want to hear people reporting about
the real issues.
o       Wembo: Infrastructure problem is questionable. Pull versus
Push sounds to me like an implementation problem.
o       Rony Even: What is the application you are using? Do you want
to use it TV-Like. Then start up delay and delay could be an issue.
o       Cisco: All implementation wait with the request of the next
chunk, until your current chunk is transmitted, you have to make the
buffer big enough. That is not a real problem.
-       No QoE Improvement Support.
-       HTTP Streaming Use Case: Life Streaming Media Broadcast.
o       Steward Cheshire:  Be cautious to compare this with the
current TV broadcasting. Concept of browsing channels may not be
important for the future.
o       Rony Even: I like to watch U2, but I want to switch between channels.
o       Steward Cheshire:  RTP get is not necessary slower then RTSP switching.
o       With RTP, there are some additional roundtrip times you have
to take into account.
o       Jörg Ott: This is not a channel switching issue.
o       Steward Cheshire:  RTP is not applicable for real time media.
o       Jörg Ott: This is not true.
o       What could be done better? HTTP can setup a connection much
faster.  Pre-asses bandwidth could reduce the needed buffer size a
lot. Assessing of bandwidth costs time.
o       Cullen Perkins: Absolutely. RTP has shorter times here. TCP
has a shortly larger delay for setup here. But will be less important
in future.

Are we discussion technical issues of HTTP streaming or if this is
fitting into IETF work?
Gonzalo: Interesting discussion, but lets focus on the charter.
David Bryan: We want to figure out the problems, really needed to be
solved.This is not a WG building BoF.

Other SDOs involved in this issue? >Not known.
Other SDO cares about HTTP streaming as well.

Aren't there clients monitoring Quality already?
Jenkins: A lot of systems have proprietary things doing this. Post
diagnostics. Not sure about the scope.

Steward Cheshire: What are we doing here? Apple/Microsoft/Adobe have
solutions for this. This has already been done.  It would be good, if
these companies could come together to work on a common solution. This
could be done within IETF.

 "Web Server overload in case of live streaming": I do not know where
the problem is.
"Solely Rely on Multi-bit rate (MBR) encoding": Do not understand this
either. You catch HTTP, you do not care about encryption.
Jörg Ott: That all are streaming issues, not HTTP issues. We may find
some signalling points, nothing to do with protocols and especially
not with HTTP.

Idea to differentiate traffic by HTTP header:
Steward Cheshire: Not differentiating the traffic is a feature not a
bug. Priorization is a bad thing.
Many people have different opinions about.
My online banking is more important than video watching of others,
they use buffers anyway. We would need to upgrade a lot of stuff. It
was a base line in the 3GPP solution, no to change existing protocols.
Cullen Perkins: We have network provided priority systems for differentiation.
Not the content is important; it is "real-time" vs. "Non real-time".
Cullen Perkins:  "Real-time" does not necessary means it is important.
Steward Cheshire: Does this really cancel "real-time"? 5 sec buffer
delay is not really "real-time". Everybody has to scale back the
usage. You will then either have a bad experience or you have to
downgrade quality.
Cullen Perkins: Different users make priorization different.
Its about optimization, e.g. for life streaming. VoD and Life
Streaming have different requirements.

Ning Zong presented a Gap Analysis.
Cullen Perkins: Questions for clarification
Do you request "realtime" support in network on IP level? Answer  No
Do you think about multicast support on network or application layer?
Answer:  Application layer multicast.
Steward Cheshire: A Useful contribution from IETF would be: Bring
together all different solution provider. Unifying this chaos could be
a useful thing.

How many of these issues have protocol impacts (modification) or just
implementation effects?
Answer: In some use cases, we will have to modify something.
Work about latency would be useful. Problems with need for protocol
modification have to be identified.
Other SDOs want to avoid protocol modification at all. We should start
looking about ways to improve the situation here.
Cullen Perkins: We already have solved these problems. There are some
system design issues here. It is not particular clear, if IETF is good
in system design. It is an issue of adaptation and rate control.
Congestion control could be an issue for IETF as well.
Spencer Dawkins: Does this requirement forces modifications to HTTP
servers? If yes, then it starts to be something else then HTTP
streaming. It will be something else. If you are using TCP you are not
doing HTTP streaming any more.
Not sure, if we can reach a big improvement here. What about fairness
in the internet?
Perhaps startup time can be decreased.  Would this be a IETF or IRTF issue?

---

Notes by Ben Niven-Jenkins

HTTP Streaming bar BoF

---
Only include company affiliations if people mentioned them at the mike

---

Slides on Goal & Scope - Qin

Marshall - does segmented into many chunks mean segmented into many
TCP sessions?

Qin - no you break the streaming file into chunks (could be separate files)

David Bryan - instead of ??? its the local reconstruction & playback

??? adapt the quality of chunks to the rate and the TCP stream does the recovery

Colin Perkins - these systems try to monitor TCP download rate &
choose next chunk based on that - maybe 1 or multiple TCP connections

Qin - can setup 1 or multiple connections, can choose chunk size e.g.
quality, bitrate

?? - more interesting to study what applicable to clients????

Magnus - Haven't you forgotten 2 most important reasons its popular -
1 it just works through firewalls etc & 2 its reasonably cost
effective

??? - (missed what he said)

Barry Levine - 2 Qs - 1) why need HTTP streaming to support this in
browser as you'll have to write an app anyway & it can speak any
protocol. 2) as TCP??? doesn;t support this what do you need that
isn;t supported by those protocols

Stuart ?? - apple - agree from apple's POV it's not to do with the web
browser - it needs an app to do this, it's about the network with
firewalls, proxies, squid caches etc. the network is optimised for
HTTP. if want a good viewing experience for most clients then make
protocol look like what network is optimised for.

??? - 1 question now have broswers with HTML5 video streaming what do
they actually do / use for streaming solution.

apple dude - background on how it evolved & i was one of the people
that argued for this. Apple RTP streaming never worked very well & was
not mainly used for streaming but files on disk. Was push back from
RTP team saying have to use RTP for video & HTTP is a hack but it's
not a hack it's the right protocol regardless of NAT & firewalls -
want to use same protocol you use for any other data - itunes just
uses HTTP get for streaming music. This is next evolution for playing
near-live. it's not for video con or interactive, but watching sports
match etc then 5-10 seconds delay doesn;t matter.

Pull slide (slide 9) - David - this is just one current design as an
example, they are multiple others.

Colin Perkins - how many of these implementation issues are with
particular clients Vs protocol issues?

Qin -

??? - how big are your chunks?

Qin -

Jeff - have seen networks with 16k of cookies? sometimes is more
overhead than you expect?

Francois - segments are of the order of seconds 2-10 seconds of video
asset at nitrate

Ben Niven-Jenkins - how many are real problems users see Vs theoretical

apple - this how you wtch video on iphone & the only way because app
store licence says its the only way you're allowed because of
arrangements with network operators who want to be able to cache
content.

Ben Niven-Jenkins - not my question which was I know people are using
this but which of these problems are users actually seeing in real
deployments

apple - good Q not working directly but my understanding is your point
is right this is working pretty well so I'm these may be theoretical -
it's not causing pain to apple at the moment.

David - dude from netflix commenting on list - he felt there were
problems but different to the ones presented here. I think it's a fair
question & one to get discussion on the list - what are the real
problems & are these the right one etc.

??? (Google) - ???? if case of pull have overhead, if doing push it's
not a problems ????? doesn;t support request chunking so can;t push
data but that's probably not problem we're dealing with here. push Vs
pull is regardless of protocol.

Roni Evan - I think issue of what is the app you are using? if you
start streaming after initial delay ??? you buffer. do you want to use
like TV with channel switching then startup delay is an issue.

Ali Begen (Cisco) - last bullet (slide 11) all approaches I
investigated, none of them does this. all wait for previous chunk to
complete before sending next request, you have enough sufficient
buffering time in streaming client so if you send request earlier you
get into bigger problem as may slow down current process so I don;t
think this is a valid problem. Even in startup phase is not a big deal
as always start with lower bitrate chunk

(20:00)

Staurt (apple) - I would caution against falling into trap which is to
emulate the way TVs work now. changing channels is something you do
with analogue TV with hundreds of channels, when you have youtube etc
don;t change channels just watch what you want to watch. my children
have no concept of channels - just pick programme & watch. Doing a lot
of work to reduce channel switching latency may be a waste when you
don't actually have channels.

Roni - I like to switch between things.

Barry Levine - channel switch latency becomes ???

Sturat - not sure HTTP get is any slower than a RTCP thing - 1 RTT is
the same regardless of protocol.

Colin Perkins - at least part of the reason is additional TCP
handshake, slow start etc. Whether that is enough to care about is
debatable but there are extra RTTs for TCP based solution than RTP.

??? - missed what he said…not a channel switching problem

Stuart - after many years of ??? apples RTP solution enforces 1 3
second day - argued it should be configurable but apple team said no -
RTP not good for real time media. I have video cameras with network
where HTTP stream is instantaneous and RTP stream has a lag.

??? - ??? not true what you said

Stuart - if network issues RTP is not going to get through where HTTP doesn't

Francois - pay devils advocate. when watch with adaptive streaming you
wait because of how it works with large buffer fill before playout.
once established works well but takes buffer to compensate. arguably
if had a system where could better pre-assess bandwidth that's
available could decide that.

Colin - ???

Ben Niven-Jenkins - whats diff between pre-assess bandwidth & buffer
fill - both take time

Francois - yes both take time. question is can we reduce startup time.

Marshall - are we discussing technical merits or whether this should
be done in IETF

David - i think this is useful but at some point we need to cut it off

??? - interesting thing about con may be the applicability statement.
whether ??? is not going to help with charter & applicability.

David - we really want to get a sense of what are the problems really
need to be solved but we want to focus on the problems faced by folks
doing this.

Peter SA - this is not a WG forming bar BoF

Colin - 2 Qs - 1) is there anything we can do to reduce overhead of
initial RTTs for TCP congestion but perhaps things to think about

??? (A) - no sub Qoe feedback - is a general ?? or complete lack of
work here or in other fora

Qin - ???

??? (A) - ??? essentially propose to use same QoS metrics for ???
streaming & HTTP streaming - I can post a link.

Magnus - wasn;t there someone posting to the list saying proprietary
stuff in the client.

Ben Niven-Jenkins - QoE feedback may be useful not for content service
provider (they have proprietary solution) but for intermediaries maybe
not to adapt but for diagnostics.

Ping - i think a lot of people talk http streaming & look at
apple/netflix & say no problem to be solved. what if we have STB using
this? those are the issues that will probably come up. we should
probably have open mind on whats happening in future. maybe need
switch channels or have feedback. let's keep open mind.

Stuart - comment on what are we doing here. apple have live, MS has
similar, Adobe has similar, Canvas, MPEG etc working on this in
fragmented way & a few people said maybe it'd be good if all people
doing this got together and then Q is what is right venue & IETF is a
candidate. From apple's POV engineers are not pushing this but will
co-operate oif there's interest. not "chomping at the bit"

(20:20)

(Slide 13)

Ali - on 1nd issue I don;t understand what problem is. using HTTP to
make use of caches so origin server is not going to push to all
clients watching live stream or there's something called content
pre-positioning that all major CDNs do.

Qin - you assume all streaming content can be cached in the middle.

??? - describe ??? none of this is specific to HTTP streaming. More
general - how design systems/networks.

Ben Niven-Jenkins - last but one Q. True there may not be a cache in
the middle but any solution that assumes there won't ever be a cache
is broken.

(Slide 14)

Stuart - not differentiating traffic is feature not problem - as soon
as start saying my bytes are more important than yours - it's
slippery. if I want to update Mac OS and daughter wants content - I'm
more important than her.

Hassna - for ?? mechanism is not HTTP only it's a generic approach.
What's not clear are you considering open qs as points to be
considered in this work - how do these two points [on the slide] fit
into IETF - would you rely on certain protocol like HTTP . how would
advance open issues.

Qin - ??? many people just looking for feedback on this area and do something

Ali - when trying to do something like online banking that is more
important http traffic to me than someone watching video in my home.
when you say prioritisation this came up in mailing list maybe ???.
Depends on type of subscriber for your service provider. we want
mechanisms in network layer should mess with HTTP headers as have to
upgrade all infrastructure and is one of the prime design
consideration in MPEG. Maybe discuss in IETF as IETF owns those
protocols but other ors have been strict in following no changes to
protocols.

Ping - that's a separate eissue if everything go through HTTP?????

Colin - we have network based QoS mechanisms not clear we need
anything different to go in HTTP stream. ???? better to put something
in streams than rely on DPI.

?? - ???

Colin - relate time doesn;t necessarily mean importnant.

???? - ???

Stuart - debate about whether this counts as real time as 5 seconds is
long time for computer. If network doesn;t have bandwidth for both
users, no who gets to suffer & who doesn;t is not obvious. Only way to
get it to work is everyone scales back.

Ni Hong??? - real time is very important to me as spend 90% time in
network to watch video/movie and I like to put other web browsing in
background.

Stuart - point i different users make that prioritisation differently.
Video is not necessarily real-time. True real-time is when there's
camera & mic. any data sotre don disk is not real-time.

??? - about optimisation, if doing live streaming buffering may be
different to delivering a file. Clarify if purely about live streaming
or both live & VoD they're different applications

Qin - just live streaming.

(slide 15) (20:35)

????

---
Survey & Gap analysis - Ning ???

(Gap Analysis slide)

Colin - 11 Qs for clarification. when say real time support in n/w you
mean at IP layer or middle boxes

Presenter - middle boxes

Colin - when say multicast support do you mean network level or
application layer

Presenter - application level not IP multicast

Spencer Dawkins - as we move down road to actual BoF BoF be careful
about labelling it as application level mast as leads people to wrong
conclusions.

Presenter - not proposing each read work item should be worked on here.

David - surprised no one has comments on this slide but could be
because its late

Stuart - my view on useful contribution IETF could do is bring
together all the disparate bits. press was great. unifying that chaos
could be useful. things labelled in red are probably red because
people don;t feel they need them or the cost of doing them is not a
benefit.

Ping - another way of looking at it how many of these really need
protocol change Vs engineering effort with existing protocols or are
implementation specific.

Extending it means make mod to existing protocol. most stuff in red,
what if just use existing protocol as is & re-engineer.

Presenter - thats possible but to use as-is in some use cases then
that may be worse than modifying something.

??? - agreed with what Ping just said. Here generally we're talking
about multimedia streaming which is not specific to HTTP . Within IETF
???? For me with my experience of server side lots you can do. here
we're just talking about live HTTP over Internet.

Ping - let me clarify. lot of experience in ??? need …

Ali - few minutes ago I said existing organisations struicly require
no changes to protocols. if doing same stuff they're doing by the time
we do anything it will be too late.

Colin - with my ex-AVT chair on I'd say we've solved that problem but
I'm biased. To some extent agree with stuart there are some system
design issues. clearly some benefits to not having 3 or 4 slightly
different ways to do same thing. It's not clear IETF is good at system
design. One thing IETF could add value but not clear there is push for
it is in adaptation algorithms & how one does rate control.

Ben Niven-Jenkins - don;t make assumption it's just live HTTP over
Internet as experience shows that never stays the case.

Spencer Dawkins - ??? Ipv4. One of conversation on list is does this
require changes to HTTP servers whatever this is or intermediate
nodes. when the answers start turning into yes it stops being HTTP
streaming & changes into something else pretty quickly. Some people on
mailing list say "yeah I really talking about improve the way things
do start-up" so well TCP will constrain a lot of that if you use TCP.
If you use something else then you're not doing HTTP Streaming
anymore.

Francois (Cisco) - wanted to make similar points to Colin on systems
things. One are where IETF could help but don;t know if there is big
improvement to be gained, is interesting adaptation thing happening &
not just closed loop system. What happens when have 10 clients share
the same, is it ???, is it fair. Maybe doesn't matter, maybe does.
IETF could make that better but not sure should be WG or research
group. This seems like right area with right expertise.

Ali - read papers on TCP window size changes would cause Internet to
collapse. So maybe we will work on this and come up with good
transport protocol for HTTP layer which is fairer for streaming
sessions or reduce startup latency. Why should;t we look at that
problem rather than try to solve problem bunch of other people already
solving. by time finish this work it will be 3 years. I went to MPEG
not pleasure but had to go there they will finish in next year so we
should look at 3-5 years.

Peter SA - question on whether that is engineering effort or marketing effort.

(21:00)

David - point to get people talking rather than specific end goal.
Want list to try to figure out what people think are the problems out
there & is this the right place. We're clearly not done need to go to
list. DO ADs have something to add

No