Subject: [httpstreaming] Agenda and Slides

From: "David A. Bryan" <[email-masked]>
Date: Sun, 7 Nov 2010 14:37:19 +0800

I just uploaded an agenda and the current slides from the
participants. The slides are available as links from the agenda, which
I have uploaded here:

http://www.p2psip.org/httpstream/79/Agenda.html

I still don't know which room is the IESG room, but I will find out
and post here shortly.

Thanks, and see you all on Wed.

David

---

From: Qin Wu <[email-masked]>
Date: Sun, 07 Nov 2010 15:21:58 +0800

Hi,
If we take IESG room, do we have the data projector available between 19:30 ~21:00?

Regards!
-Qin
----- Original Message ----- 
From: "David A. Bryan" <[email-masked]>
To: "httpstreaming" <[email-masked]>
Sent: Sunday, November 07, 2010 2:37 PM
Subject: [httpstreaming] Agenda and Slides

> _______________________________________________
> httpstreaming mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>

---

From: Qin Wu <[email-masked]>
Date: Sun, 07 Nov 2010 20:29:01 +0800

Hi,
This is just a quick note to let you know that  our meeting room for HTTP streaming discussion has been changed 
from IESG room to room Emenrald at Level 3.

David, Can you update our agenda at the links
http://www.p2psip.org/httpstream/79/Agenda.html

Thanks!

Regards!
-Qin

---

From: Mark Watson <[email-masked]>
Date: Tue, 9 Nov 2010 12:39:17 -0800

All,

My apologies for not being able to attend tomorrow's meeting.

I took a look at the slides and have a few comments.

Overall, I am really concerned that the suggestions for problems and areas that need to be addressed are based on an incomplete understanding of how HTTP Streaming is working today and an incomplete analysis of the problems that do exist for real deployments of this technology. We really need a more complete analysis of the problems before jumping into solutions. "Problems" are frequently stated in the slides as "there is no support for X", where X is some feature. This is not a problem - this is a suggestion for a solution (feature X). We need to know what actual problems users and service providers see that are in scope of the IETF to look at, not just which new technologies people would like to look at.

Some specific comments on the Qin Wu slides:

Slide 4: I hope this is not really the goal of your meeting tomorrow ;-) Perhaps it is a proposal for a WG charter goal ? You should be very clear what is meant by "efficient" and what is meant by "transport". If you mean Transport Layer, say that. Overall the goals are too high-level: noone could disagree that subscriber QoE requirements should be met (if they are indeed requirements this is tautological).

Slide 5:
- I'm not sure I agree with the definition. Yes, streaming is characterized by a timing relationship between delivery and rendering, but this doesn't imply "steady and continuous"
- The use of chunks has very little to do with "large packet dropout rate due to TCP", whatever that is.

Slide 6:
- The motivations for HTTP streaming on this slide are completely wrong. HTTP Streaming is popular (1) because it is based on re-use of existing web infrastructure which is successfully operating at Internet scale and (2) because of the possibility for real-time adaptation (to network conditions, but also device capabilities and user preferences). Device capabilities could be incorporated in the "multi-screen" point, but is nevertheless secondary. It has almost nothing to do with browser support - many HTTP streaming solutions do not use the same HTTP stack as the browser anyway.

Slide 7:
- It would be nice to mention the largest HTTP streaming service in terms of hours viewed (Netflix). Especially as we are very much involved in standardization efforts. 

Slide 9&10:
- You should note here that "chunks" are not necessarily separate files on the web server, but may be identified by byte ranges or other means.

Slide 11:
- I'm not buying that HTTP delivery is especially "inefficient". Compared to what ? I think you need to quantify the inefficiency - at least back-of-envelope - to state this as a "problem".
- I don't understand the first bullet
- The second bullet seems to be issues with procedures, rather than protocols

Slide 12:
- I disagree that there are no techniques using the existing protocols that can improve QoE - we are doing this all the time ;-)
- "Best effort internet" - I agree with the sub-bullet, but I am not sure what this has to do with "best effort" - if there is insufficient capacity then there is insufficient capacity. Slicing and dicing it just moves the problem.
- Standards for QoE reporting would be useful. We proposed this in MPEG. I disagree that this is more difficult in the client pull model. Our clients provide us with copious information which is much easier to manage than server logs would be (because it is the client which has a notion of "session" to report on). Only the client knows what the user actually saw.
- I don't know why you would continually update the manifest. I know some systems do this for live, but it still seems unnecessary to me.

Slide 14:
- As I mentioned in email, it's not clear to me that HTTP streaming traffic should be prioritized over web traffic. But anyway, I think you are addressing the issue the wrong way around. The question should be: given a particular profile of available bandwidth, how do I deliver the best possible service to the user ? If, in some environment, that profile is guaranteed to be constant high data rate, by some prioritization or QoS mechanism, then great. But in other envionments that is not the case and we still need to deliver service.

Slide 15:
- I don't understand this one at all. The possibility to use existing distributed web infrastructure and caching is exactly the primary motivation for HTTP Streaming. CDNs do a lot of things already that make their systems work efficiently. Is the proposal that we standardize how CDNs work ? Should we have some CDN representatives present before embarking on that ?

...Mark

---

From: Qin Wu <[email-masked]>
Date: Wed, 10 Nov 2010 08:58:39 +0800

Thank you, Mark,we will take your comments into consideration at the meeting.

Regards!
-Qin

---

From: "Kathy McEwen" <[email-masked]>
Date: Tue, 9 Nov 2010 21:42:45 -0600

Hello,

  Unfortunately we were unable to make it over to Beijing for these IETF
meetings (apologies).  

I did want to contribute a few comments on the draft and the slides though,
particularly around the scope/problem statement.  

Our focus has been almost exclusively on video over the top of the web, and
we have been engaging many North American and European media companies and
network providers over the past couple of years.  Something that has come to
light (repeatedly) has been the issues around consumers consumption of video
over mobile.  Mobile conditions can very greatly from cell site to cell
site, depending on access technology (2G, 3G, 4G, WiFi, etc.), interference,
user load conditions, backhaul load conditions, transit/interconnect load,
etc.  

There are many heterogeneous mobile network providers globally, that have a
large variety of many generations of mobile access technologies, which by
their very nature allow users to handoff easily between the generations of
access.  It takes years to roll out new access technologies, so users are
often handing off between old to new, new to newer, and newer to old again
while consuming content over the mobile web.  

Video represents a very large load to the older mobile data access
technologies, and a single average web video stream is likely to overwhelm
all user's on an older generation cell site, that could be managed much
better.  This problem will only continue as mobile network operators begin
rolling out 4th generation technologies.  

Mobile providers could adopt technologies to take all video traffic and
transcode it down to the lowest common denominator, but would user's really
want to be watching video adapted to 2G speeds (40-120 kpbs/average) when on
4G (2, 3... 100 mbps??)? Not likely. Then there are loads of issues with the
cost of doing that, as well as the messy potential legal issues of messing
around with a professional content providers media.  

History has demonstrated that there can be co-operation between media
companies, network carriers and consumers, that would perhaps allow for a
different approach of delivery. After doing some digging on the various
protocols (RTMP/http, RTSP, HTML5/http, etc... ), we found that all of them
that are doing any kind of adaptive rate streaming, but they do not today
incorporate the messages/control mechanisms to allow for the network to take
control and adapt the rate of the video.  

Adapting streams (like AMR does in the mobile domain) is something that the
network knows how to do best, and video over the web could benefit greatly
(from user's quality of experience as well as network providers costs,
customer satisfaction, etc) from having some sort of network involvement.
It would be good to show some of the statistics around mobile consumption of
video, and examples of where mobile network co-operation with web video
application's need/benefit.

  .../Kathy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Bryan
Sent: Sunday, November 07, 2010 1:37 AM
To: httpstreaming
Subject: [httpstreaming] Agenda and Slides

I just uploaded an agenda and the current slides from the participants. The
slides are available as links from the agenda, which I have uploaded here:

I still don't know which room is the IESG room, but I will find out and post
here shortly.

David

---

From: Mark Watson <[email-masked]>
Date: Tue, 9 Nov 2010 20:24:07 -0800

Sent from my iPad

On Nov 9, 2010, at 7:42 PM, "Kathy McEwen" <[email-masked]> wrote:

> After doing some digging on the various

But it does! It drops packets, causing a congestion response from TCP causing in turn an adaptation by the application. The network is completely in control of the packet delivery rate, which the application knows and adapts to.

This is the baseline, which is so simple and applicable across myriad access technologies. New mechanisms need to justify themselves against this baseline.

...Mark

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 10 Nov 2010 13:13:29 +0800

Hi,

I agree Kathy here.
And, Mark, yes, you are right, it drops packets. But this is only a passive reaction, I think it is better to achieve some active operation, or proactive operation (if possible), that would be perfact.

I think these jobs are worthy our attention.

Best Regards
Xiangsong

----- 原邮件 -----
发件人: Mark Watson <[email-masked]>
日期: 星期三, 十一月 10日, 2010 下午12:24
主题: Re: [httpstreaming] Agenda and Slides
收件人: Kathy McEwen <[email-masked]>
抄送: httpstreaming <[email-masked]>

> But it does! It drops packets, causing a congestion response from 
> TCP causing in turn an adaptation by the application. The network 
> is completely in control of the packet delivery rate, which the 
> application knows and adapts to.
> 
> This is the baseline, which is so simple and applicable across 
> myriad access technologies. New mechanisms need to justify 
> themselves against this baseline.
> 
> ...Mark

---

From: David R Oran <[email-masked]>
Date: Wed, 10 Nov 2010 10:52:40 -0500

> And, Mark, yes, you are right, it drops packets. But this is only a passive reaction, I think it is better to achieve some active operation, or proactive operation (if possible), that would be perf…
Why? This is not at all obvious to some of us, unless by "proactive" you mean turning on existing machinery that is not yet universally deployed, like RED and ECN. There is at least some evidence that currently measured poor adaptive streaming behaviors can be explained by tail-drop routers hanging around all over the place. TCP is known to behave badly under heavy load with tail-drop queuing. I think you'd agree that it's a whole lot easier to turn on  well understood, standardized and nearly universally implemented techniques at the network layer than it it is stumble around trying to invent new application and HTTP machinery to try to fake it out.

We also don't fully understand the effect of allowing adaptive streaming clients to compete only against each other with no cross traffic present to inject enough noise to drive the adaptation algorithms. The deployments today are without putting the traffic in a separate QoS class since they run over-the-top on BE service. It is far from clear that removing the cross-traffic induced bandwidth variation will make things better - it might, counter-intuitively, make things worse!

> I think these jobs are worthy our attention.
I do not think the case has yet been made, although I think you'll find we're all open minded and willing to listen.

With respect to the mobile environment specifically, there is an obvious space/time/computation/bandwidth tradeoff with respect to multi-rate coding (upon which adaptive HTTP streaming depends). If you only have a few rates to play with, it's obviously hard to to optimal bandwidth packing on radio channels that don't support enough users to satisfy the "law of large numbers". It's even harder to do it with good fairness properties. There are many ways to skin this cat though:

- spend the cycles on the encoders and space in the caches to have finer rate quantization in the multi-rate coding.
- match the encoding rates to to the radio channel allocation chunks
- transrate a higher rate down to fit in the allocation for a given mobile user if that would result in better QoE than shifting them down to the next lower rate.

However, I'd like to observe that NONE of these techniques has much (or at least very little) to do with the protocols and algorithms for adaptive HTTP streaming.

There may be some small tweaks that one might do though. For example, there might be useful transrating hints in server manifests to tell streaming servers whether they are permitted to transrate a given profile, and hints in client manifests to allow them to request a transrate down as opposed to shifting to the next lower coding rate. Alternatively, the manifests could just lie about the number of profiles, and allow servers to "synthesize" the intermediate profiles by transrating.

As a parting homily to those who think reservations and admission control are always superior to adaptation in their ability to deliver QoE, remember that:

"The purpose of bandwidth reservation and admission control is to say NO, not to say YES". If you can always say YES, you don't need it, and if you say NO a lot, you are just quantizing unfairness into a boolean."

DaveO.

> <c00111037.vcf>_______________________________________________

---

From: Kathy McEwen <[email-masked]>
Date: Wed, 10 Nov 2010 16:31:57 -0800

How about the mobile handoff scenario from 3G to 2g where the 2g has only ATM backhaul from the radio, no TCP interaction.  .... How does the network and the handset use adaptive rate encoding, http and tcp then? 

Sent from my iPhone

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 11 Nov 2010 00:17:43 -0800

Can 2g provide acceptable video quality anyway even if everything is close to be perfect? During such a handoff, many things will probably fail to work... it certainly won't be that seamless to the client.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Kathy McEwen
> Sent: Thursday, November 11, 2010 8:32 AM
> To: Dave Oran (oran)
> Cc: httpstreaming
> How about the mobile handoff scenario from 3G to 2g where the 2g has only ATM backhaul from the radio, no TCP
> interaction.  .... How does the network and the handset use adaptive rate encoding, http and tcp then?
> 
> Sent from my iPhone
> 
> >> And, Mark, yes, you are right, it drops packets. But this is only a passive reaction, I think it is better to achieve some active
> operation, or proactive operation (if possible), that would be perfact.
> >>
> > Why? This is not at all obvious to some of us, unless by "proactive" you mean turning on existing machinery that is not yet
> universally deployed, like RED and ECN. There is at least some evidence that currently measured poor adaptive streaming
> behaviors can be explained by tail-drop routers hanging around all over the place. TCP is known to behave badly under heavy
> load with tail-drop queuing. I think you'd agree that it's a whole lot easier to turn on  well understood, standardized and
> nearly universally implemented techniques at the network layer than it it is stumble around trying to invent new application
> and HTTP machinery to try to fake it out.
> >
> > We also don't fully understand the effect of allowing adaptive streaming clients to compete only against each other with no
> cross traffic present to inject enough noise to drive the adaptation algorithms. The deployments today are without putting
> the traffic in a separate QoS class since they run over-the-top on BE service. It is far from clear that removing the cross-
> traffic induced bandwidth variation will make things better - it might, counter-intuitively, make things worse!
> >
> > With respect to the mobile environment specifically, there is an obvious space/time/computation/bandwidth tradeoff with
> respect to multi-rate coding (upon which adaptive HTTP streaming depends). If you only have a few rates to play with, it's
> obviously hard to to optimal bandwidth packing on radio channels that don't support enough users to satisfy the "law of large
> numbers". It's even harder to do it with good fairness properties. There are many ways to skin this cat though:
> >
> > There may be some small tweaks that one might do though. For example, there might be useful transrating hints in server
> manifests to tell streaming servers whether they are permitted to transrate a given profile, and hints in client manifests to
> allow them to request a transrate down as opposed to shifting to the next lower coding rate. Alternatively, the manifests
> could just lie about the number of profiles, and allow servers to "synthesize" the intermediate profiles by transrating.
> >
> > "The purpose of bandwidth reservation and admission control is to say NO, not to say YES". If you can always say YES, you
> don't need it, and if you say NO a lot, you are just quantizing unfairness into a boolean."
> >
> > DaveO.
> >
> >
> >
> >
> >> Best Regards
> >> Xiangsong
> >>
> >>
> >> ----- 原邮件 -----

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 11 Nov 2010 17:10:37 +0800

Hi David,

In fact I have no clear picture in my mind, I am thinking,

#1, It seems the current adaptive HTTP streaming is based on endpoint (client or server), is it possible or useful that the middle-box trigers stream rate adjustment? 
    In my mind, a similar case is ECN mechanism, router forwards IP packets between TCP endpoints. The router doesn't support TCP protocol, but the router can be involved in TCP flow control (or TCP rate adjustment) by some IP header indication. Can the middlebox also influence HTTP streaming by some mechanism more effectively? I think network-based or network-involved HTTP streaming mechanism may be a supplement to client-based mechanism. 
RED is OK, but whether it is better that rate adjustment happens earlier than packet drop? Some resource in the foregoing path is wasted by dropped packets ...

#2, In mobile envirment, network has a more clear map (channel, bandwidth, etc.) than the client, if the network can trace the mobile client, can the network make some proactive operation on HTTP streaming? I'm not sure.

Best Regards
Xiangsong

----- 原邮件 -----
发件人: David R Oran <[email-masked]>
日期: 星期三, 十一月 10日, 2010 下午11:52
主题: Re: [httpstreaming] Agenda and Slides
收件人: Xiangsong Cui <[email-masked]>
抄送: Mark Watson <[email-masked]>, httpstreaming <[email-masked]>

> > And, Mark, yes, you are right, it drops packets. But this is 
> only a passive reaction, I think it is better to achieve some 
> active operation, or proactive operation (if possible), that would 
> be perfact.
> > 
> Why? This is not at all obvious to some of us, unless by 
> "proactive" you mean turning on existing machinery that is not yet 
> universally deployed, like RED and ECN. There is at least some 
> evidence that currently measured poor adaptive streaming behaviors 
> can be explained by tail-drop routers hanging around all over the 
> place. TCP is known to behave badly under heavy load with tail-
> drop queuing. I think you'd agree that it's a whole lot easier to 
> turn on  well understood, standardized and nearly universally 
> implemented techniques at the network layer than it it is stumble 
> around trying to invent new application and HTTP machinery to try 
> to fake it out.
> 
> We also don't fully understand the effect of allowing adaptive 
> streaming clients to compete only against each other with no cross 
> traffic present to inject enough noise to drive the adaptation 
> algorithms. The deployments today are without putting the traffic 
> in a separate QoS class since they run over-the-top on BE service. 
> It is far from clear that removing the cross-traffic induced 
> bandwidth variation will make things better - it might, counter-
> intuitively, make things worse!
> 
> I do not think the case has yet been made, although I think you'll 
> find we're all open minded and willing to listen.
> 
> With respect to the mobile environment specifically, there is an 
> obvious space/time/computation/bandwidth tradeoff with respect to 
> multi-rate coding (upon which adaptive HTTP streaming depends). If 
> you only have a few rates to play with, it's obviously hard to to 
> optimal bandwidth packing on radio channels that don't support 
> enough users to satisfy the "law of large numbers". It's even 
> harder to do it with good fairness properties. There are many ways 
> to skin this cat though:
> 
> - spend the cycles on the encoders and space in the caches to have 
> finer rate quantization in the multi-rate coding.
> - transrate a higher rate down to fit in the allocation for a 
> given mobile user if that would result in better QoE than shifting 
> them down to the next lower rate.
> 
> However, I'd like to observe that NONE of these techniques has 
> much (or at least very little) to do with the protocols and 
> algorithms for adaptive HTTP streaming.
> 
> There may be some small tweaks that one might do though. For 
> example, there might be useful transrating hints in server 
> manifests to tell streaming servers whether they are permitted to 
> transrate a given profile, and hints in client manifests to allow 
> them to request a transrate down as opposed to shifting to the 
> next lower coding rate. Alternatively, the manifests could just 
> lie about the number of profiles, and allow servers to 
> "synthesize" the intermediate profiles by transrating.
> 
> As a parting homily to those who think reservations and admission 
> control are always superior to adaptation in their ability to 
> deliver QoE, remember that:
> 
> "The purpose of bandwidth reservation and admission control is to 
> say NO, not to say YES". If you can always say YES, you don't need 
> it, and if you say NO a lot, you are just quantizing unfairness 
> into a boolean."
> 
> DaveO.
> 
> 
> 
> 
> > Best Regards
> > Xiangsong
> > 
> > 
> > ----- 原邮件 -----
> >>> protocols (RTMP/http, RTSP, HTML5/http, etc... ), we found 
> that 
> >> all of them
> >>> that are doing any kind of adaptive rate streaming, but they 
> do 
> >> not today

---

From: David R Oran <[email-masked]>
Date: Thu, 11 Nov 2010 10:44:31 -0500

> #1, It seems the current adaptive HTTP streaming is based on endpoint (client or server), is it possible or useful that the middle-box trigers stream rate adjustment? 
I sure hope not, unless by "middlebox" you mean a real HTTP server at the edge of the CDN. Otherwise you get no sympathy from me as I am on record as finding middleboxes a pretty universally bad thing. If you mean special machinery in the edge HTTP server looking into the access network (e.g. mobile, DSL, etc.) then I think there *might* be something (as I said, I'm open minded), but it's up to the proponents of doing stuff on the HTTP servers to make the case that it provides more than a small measurable benefit and doesn't break anything.

>    In my mind, a similar case is ECN mechanism, router forwards IP packets between TCP endpoints. The router doesn't support TCP protocol, but the router can be involved in TCP flow control (or TCP rate adjustment) by some IP header indication.
ECN does not involve the router in a TCP flow. What makes you think it does? It's a pure L3 mechanism with no examination of TCP headers nor tracking of TCP state.

> Can the middlebox also influence HTTP streaming by some mechanism more effectively? I think network-based or network-involved HTTP streaming mechanism may be a supplement to client-based mechanism. 
Well, the potential design space is gigantic. Most of it is complicated and has lots of tradeoffs. Imagining that you might do something better is not sufficient. You have to:
a) propose something
b) analyze it
c) simulate it under a wide range of conditions
d) implement it
e) measure it on the real internet (or an overlay like Planetlab).

Get there and them maybe the IETF should have another BoF to look at the problem.

> RED is OK, but whether it is better that rate adjustment happens earlier than packet drop? Some resource in the foregoing path is wasted by dropped packets ...
That's not what RED is about. It's about breaking up the well-known synchronization behavior of tail-drop on TCP, which leads to oscillations and significant underutilization of bottleneck link bandwidth. It isn't about improving the performance for any one connection. RED is basic hygiene, not an optimization. My point was that designing complicated TCP or HTTP level mechanisms to try to get around tail-drop router induced performance problems is a waste of effort when you can just torn on RED. What data do you have that the performance anomalies you're trying to eliminate are NOT due to tail drop?

> #2, In mobile envirment, network has a more clear map (channel, bandwidth, etc.) than the client, if the network can trace the mobile client, can the network make some proactive operation on HTTP s…
Again, "not sure" isn't good enough. (I'm not sure if I might win the lottery). I don't think we've even gotten to step (1), which is demonstrating with real numbers and real measurements that there is a problem to be solved here. Then we need step (2) which is seeing if the problem has any feasible solutions that don't break other things, or overcomplicate the architecture. Then we can get to step (3) which is to compare the solutions against the baseline of doing nothing. At that point if enough improvement is demonstrated to warrant spending a lot of the IETF's time standardizing something, we can work on the details.

My fear here is that we'll have a problem statement that boils down to "we need nano fiber transport cables to geosynchronous orbit" at one extreme, or "it sure would be nice if streaming HTTP made better use of scarce radio resources on 4G networks" at the other.

I don't think the case has yet been made that there's a well-scoped problem for IETF to work on here. I heard somebody proposed that perhaps an IRTF research group ought to be the first step. That might be an alternative worth considering, but only if we can get the right people actually doing work (i.e. researchers with the right skill sets and resources to do the modeling, simulation, and experiments).

Cheers, DaveO.

> <c00111037.vcf>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 11 Nov 2010 16:34:21 +0000

Dave, 

Thank you, the extract of your e-mail that I have included below precisely describes my concerns with the httpstreaming drafts/proposal in a much more eloquent way than I could have expressed it myself.

Ben

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 12 Nov 2010 10:19:24 +0800

Hi David,

Again, I'm not telling any solid use case, just my some thoughts, or questions, for open discussion.
Please see my comments inline.

----- 原邮件 -----
发件人: David R Oran <[email-masked]>
日期: 星期四, 十一月 11日, 2010 下午11:44
主题: Re: [httpstreaming] Agenda and Slides
收件人: Xiangsong Cui <[email-masked]>
抄送: Mark Watson <[email-masked]>, httpstreaming <[email-masked]>

> > #1, It seems the current adaptive HTTP streaming is based on 
> endpoint (client or server), is it possible or useful that the 
> middle-box trigers stream rate adjustment? 
> I sure hope not, unless by "middlebox" you mean a real HTTP server 
> at the edge of the CDN. Otherwise you get no sympathy from me as I 
> am on record as finding middleboxes a pretty universally bad 
> thing. If you mean special machinery in the edge HTTP server 
> looking into the access network (e.g. mobile, DSL, etc.) then I 
> think there *might* be something (as I said, I'm open minded), but 
> it's up to the proponents of doing stuff on the HTTP servers to 
> make the case that it provides more than a small measurable 
> benefit and doesn't break anything.

In my mind, that is not a HTTP server, but it will do some measurement on the HTTP traffic flow.
The baseline here is, it should not break anything in the HTTP transaction.

> 
> >    In my mind, a similar case is ECN mechanism, router forwards 
> IP packets between TCP endpoints. The router doesn't support TCP 
> protocol, but the router can be involved in TCP flow control (or 
> TCP rate adjustment) by some IP header indication.
> ECN does not involve the router in a TCP flow. What makes you 
> think it does? It's a pure L3 mechanism with no examination of TCP 
> headers nor tracking of TCP state.

I didn't say router is involved in TCP flow, My point here is, the router can influence TCP endpoint (rate control aspect) by some operation except dropping.
Router may drop packet, the TCP endpoint will also detect that, and the endpoint will give some reaction. This of course works well, but it is also may be improved, right?

> 
> > Can the middlebox also influence HTTP streaming by some 
> mechanism more effectively? I think network-based or network-
> involved HTTP streaming mechanism may be a supplement to client-
> based mechanism. 
> Well, the potential design space is gigantic. Most of it is 
> complicated and has lots of tradeoffs. Imagining that you might do 
> something better is not sufficient. You have to:
> a) propose something
> b) analyze it

Yes, you are right, there are lots jobs, but I'm just wondering, is it possible?
Or maybe can tell me, why is it not possible? why is it not worthy of any consideration?

> Get there and them maybe the IETF should have another BoF to look 

If this is out of scope of httpatreaming list, we may discuss this somewhere others.

> 
> > RED is OK, but whether it is better that rate adjustment happens 
> earlier than packet drop? Some resource in the foregoing path is 
> wasted by dropped packets ...
> > 
> That's not what RED is about. It's about breaking up the well-
> known synchronization behavior of tail-drop on TCP, which leads to 
> oscillations and significant underutilization of bottleneck link 
> bandwidth. It isn't about improving the performance for any one 
> connection. RED is basic hygiene, not an optimization. My point 
> was that designing complicated TCP or HTTP level mechanisms to try 
> to get around tail-drop router induced performance problems is a 
> waste of effort when you can just torn on RED. What data do you 
> have that the performance anomalies you're trying to eliminate are 
> NOT due to tail drop?
> 
> > #2, In mobile envirment, network has a more clear map (channel, 
> bandwidth, etc.) than the client, if the network can trace the 
> mobile client, can the network make some proactive operation on 
> HTTP streaming? I'm not sure.
> > 
> Again, "not sure" isn't good enough. (I'm not sure if I might win 
> the lottery). I don't think we've even gotten to step (1), which 
> is demonstrating with real numbers and real measurements that 
> there is a problem to be solved here. Then we need step (2) which 
> is seeing if the problem has any feasible solutions that don't 
> break other things, or overcomplicate the architecture. Then we 
> can get to step (3) which is to compare the solutions against the 
> baseline of doing nothing. At that point if enough improvement is 
> demonstrated to warrant spending a lot of the IETF's time 
> standardizing something, we can work on the details.
> 
> My fear here is that we'll have a problem statement that boils 
> down to "we need nano fiber transport cables to geosynchronous 
> orbit" at one extreme, or "it sure would be nice if streaming HTTP 
> made better use of scarce radio resources on 4G networks" at the 
> other.
> I don't think the case has yet been made that there's a well-
> scoped problem for IETF to work on here. I heard somebody proposed 
> that perhaps an IRTF research group ought to be the first step. 
> That might be an alternative worth considering, but only if we can 
> get the right people actually doing work (i.e. researchers with 
> the right skill sets and resources to do the modeling, simulation, 
> and experiments).

Yes, all my messages here are very "raw" thought, so do not take it as argument for anything.

Regards,
Xiangsong

> > 抄送: Mark Watson <[email-masked]>, httpstreaming 
> <[email-masked]>> 
> >> 
> >> - match the encoding rates to to the radio channel allocation 
> chunks>> - transrate a higher rate down to fit in the allocation 
> for a