Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 9 Nov 2010 04:35:03 +0100

Hi

I have skimmed through the pdf, thanks for posting this. My immediate reaction is that this machanism is trying to react to indicators of congestion in various ways. 

An alternative would actually be ConEx (http://tools.ietf.org/wg/conex/charters). With ConEx enabled flows the re-feedback information can be used by both operator and user to verify that a SLA is met.
For instance, if a user is promised a bandwith of 200kbps for his gaming experience and still experience a high congetsion volume, this would be clearly visible for the operator (as well as the user). I don't believe that ConEx has outlined this particular use case but I would say that it should be doable.
ConEx has the benefit that it does not add much extra overhead, there are of course issues with ConEx (as with any other new technology)

Regads
/Ingemar

> -----Original Message-----
> From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) 
> [mailto:[email-masked]] 
> Sent: den 9 november 2010 00:33
> To: Qin Wu; [email-masked]
> Cc: httpstreaming
> Subject: Re: [httpstreaming] [dispatch] Q-HTTP
> 
> Hi Qin and all,
> 
> Now the Q-HTTP draft is accesible at 
> 
> http://www.ietf.org/id/draft-aranda-dispatch-qhttp-00.txt
> 
> In addition, i have attached in this email a FAQ document for 
> easier understanding of the protocol. This document clarifies 
> the philosophy and shows different alternatives for the implementation
> 
> Regards and thanks
> 
> - Jose javier
> 
> 
> -----Mensaje original-----
> De: Qin Wu [mailto:[email-masked]] Enviado el: lunes, 08 
> de noviembre de 2010 15:35
> Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); [email-masked]
> CC: httpstreaming
> Asunto: Re: [dispatch] Q-HTTP
> 
> Hi, Joes Javier:
> Your bring a quite interesting draft. We have a Bar BOF on 
> HTTP streaming on Wednesday evening, Emenrald room, which 
> aims at  building new area and working out appropriate 
> working scope to offer more efficient transport and better 
> QoE. One of key issues we are ready to address is QOE 
> improvement. If you are interested, please join our discussion.
> Also you can track the following link for our meeting agenda, 
> location and time:
> http://www.ietf.org/mail-archive/web/httpstreaming/current/mai
> llist.html
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" 
> <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 08, 2010 4:14 PM
> Subject: [dispatch] Q-HTTP
> 
> 
> 
> Hi experts, 
> 
> We are a group of researchers which have written a draft 
> about QoS measurements & reactions. We believe the 
> standardization of this topic could benefit internet 
> community in the coming years, for example for virtualization 
> of videogames through intenet. We would like to receive 
> comments and some feedback and also oppinions about the 
> target area, because we believe that the draft fits into 
> Real-time App and infrastructure Area scope, but currently 
> the draft is in "looking for an area" state
> 
>    The draft describes Q-HTTP (Quality HTTP) , which is an 
> application level protocol based on HTTP and SDP associated 
> to a new specific uri "httpq://..." intended for carrying out 
> quality negotiation and quality measurement between two 
> parties. The final goal of this process is to verify that a 
> certain application which depends on bandwidth, latency, 
> jitter parameters, will work under current network 
> conditions. Our idea tackles the fact that real-time services 
> (virtualization, on line gaming, video, voice) nowadays are 
> increasing and that in an internet (or WAN) environment 
> propagation conditions may change with time for our 
> connection; what works for most applications may not work for 
> real-time ones and they should have a standard way of 
> negotiating and verifying their requirements. Q-HTTP also 
> provides a mechanism of account/alerting when required 
> constraints are not met after the measurement is carried out.
>   
>  Implementation details on the actions to be triggered upon 
> reception/detection of QoS alerts exchanged by the protocol 
> are out of scope of this draft, it is application dependant 
> (e.g. increase quality, reduce bit-rate) or even network 
> dependant (e.g. change connection's quality profile).
> 
> Comments? Thanks
> 
> - Jose Javier
> 
> 
> 
> --------------------------------------------------------------
> ------------------
> 
> 
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 9 Nov 2010 14:20:51 +0100

Hi

I see ConEx as both a stick and carrot.
The "stick" part because it makes it possible or an operator to make sure that individual users (or groups of users) don't exceed their allowed contribution to congestion (a.k.a congestion volume). 
The "carrot" part is a consequence of the "stick" part, excessive congestion can be avoided in the networks and this means that users runs a much lower risk of experiencing high delay.

Sure you may not get the exact delay you ask for. Possibly ConEx can allow for a lightweight QoS at its best (for instance users pay extra for an extra congestion volume allowance) but perhaps a lightweight QoS is good enough ?
And... I am not convinced that full-fledged QoS gives you the delay you ask for, perhaps on longer timescales this is true. 

I am not pretending that ConEx will solve any problem in the world, there are definitely issues with ConEx and likely some data collection is needed before congestion volume policers and incentive droppers can be tuned in for a good performance, and in addition the endpoints need to be ConEx enabled.
    
Regards
Ingemar

> Sent: den 9 november 2010 18:17
> To: Ingemar Johansson S; Qin Wu; [email-masked]
> Cc: httpstreaming; [email-masked]
> Subject: RE: [httpstreaming] [dispatch] Q-HTTP
> 
> Hi Ingemar
> 
> Congestion control mechanisms and exposure give operators the 
> way to avoid problems in their networks and also reward users 
> which does not impact on others, but does not cover the need 
> for a quality in terms of latency and jitter, but only packet loss.
> 
> The scenario in which a particular user is paying to a 
> content provider to ( for example) play a virtualized game, 
> and the content provider pays to the operator in order to be 
> possible a QoS on demand (during few minutes) for the flows 
> from server to this particular user is the goal of Q-HTTP and 
> although congestion must be measured, the rest of quality 
> parameters are also important and of course the reaction time 
> of the protocol is a key factor.
> 
> In this scenario probably this particular user is 
> contributing to the congestion of others but should not be 
> penalized. Conex as a form of fifferential QoS could serve 
> this goal, but needs the help of "something like Q-HTTP" to 
> achieve the measurements. Don't you agree?
> 
> In a philosophy perspective, we need these pieces: 
>      1) a network with differential QoS capability   ( 
> diffserv, traffic engineering, PCE, traffic mode at access node, etc)
>      2) a unified measurement procedure capable to react  ( Q-HTTP ?)
>      3) something to match the reactions with the QoS 
> capability of the network ( CONEX ?)
> 
> Apart from this, in terms of overhead, Q-HTTP only uses a few 
> Kbps, and it is configurable ( more responsiveness implies 
> more kbps) but for example in our implementation, 15kbps is 
> quite good for measure downstream and 1kbps for measure 
> upstream. The responsiveness is defined at the first stage of 
> the protocol, so can be whatever content provider wants, 
> depending on the type of content.
>  
> - Jose Javier
> 
> 
> De: Ingemar Johansson S [mailto:[email-masked]]
> Enviado el: martes, 09 de noviembre de 2010 4:35
> Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Qin Wu; 
> [email-masked]
> CC: httpstreaming; [email-masked]
> Asunto: RE: [httpstreaming] [dispatch] Q-HTTP
> 
> Hi
> 
> I have skimmed through the pdf, thanks for posting this. My 
> immediate reaction is that this machanism is trying to react 
> to indicators of congestion in various ways. 
> 
> An alternative would actually be ConEx 
> (http://tools.ietf.org/wg/conex/charters). With ConEx enabled 
> flows the re-feedback information can be used by both 
> operator and user to verify that a SLA is met.
> For instance, if a user is promised a bandwith of 200kbps for 
> his gaming experience and still experience a high congetsion 
> volume, this would be clearly visible for the operator (as 
> well as the user). I don't believe that ConEx has outlined 
> this particular use case but I would say that it should be doable.
> ConEx has the benefit that it does not add much extra 
> overhead, there are of course issues with ConEx (as with any 
> other new technology)
> 
> Regads
> /Ingemar
> 
>  
> 
>   
> 
> > In addition, i have attached in this email a FAQ document 
> for easier 
> > understanding of the protocol. This document clarifies the 
> philosophy 
> > and shows different alternatives for the implementation
> > 
> > Regards and thanks
> > 
> > - Jose javier
> > 
> > 
> > De: Qin Wu [mailto:[email-masked]] Enviado el: lunes, 08 de 
> > noviembre de 2010 15:35
> > Your bring a quite interesting draft. We have a Bar BOF on HTTP 
> > streaming on Wednesday evening, Emenrald room, which aims 
> at  building 
> > new area and working out appropriate working scope to offer more 
> > efficient transport and better QoE. One of key issues we 
> are ready to 
> > address is QOE improvement. If you are interested, please join our 
> > discussion.
> > Also you can track the following link for our meeting 
> agenda, location 
> > and time:
> > We are a group of researchers which have written a draft about QoS 
> > measurements & reactions. We believe the standardization of 
> this topic 
> > could benefit internet community in the coming years, for 
> example for 
> > virtualization of videogames through intenet. We would like 
> to receive 
> target area, 
> > because we believe that the draft fits into Real-time App and 
> > infrastructure Area scope, but currently the draft is in 
> "looking for 
> > an area" state
> > 
> application 
> > level protocol based on HTTP and SDP associated to a new 
> specific uri 
> > "httpq://..." intended for carrying out quality negotiation and 
> > quality measurement between two parties. The final goal of this 
> > process is to verify that a certain application which depends on 
> > bandwidth, latency, jitter parameters, will work under 
> current network 
> increasing 
> > and that in an internet (or WAN) environment propagation conditions 
> > may change with time for our connection; what works for most 
> > applications may not work for real-time ones and they should have a 
> > standard way of negotiating and verifying their 
> requirements. Q-HTTP 
> > also provides a mechanism of account/alerting when required 
> are out of 
> > scope of this draft, it is application dependant (e.g. increase 
> > quality, reduce bit-rate) or even network dependant (e.g. change 
> > connection's quality profile).
> > 
> > Comments? Thanks
> > 
> > - Jose Javier
> > 
> > 
> >

---

From: Lars Eggert <[email-masked]>
Date: Wed, 10 Nov 2010 10:02:06 +0800

On 2010-11-9, at 18:31, David Singer wrote:
> It is that there are two ways to solve a real-time bandwidth need.  One is to reserve bandwidth, manage QoS and so on;  one gets protocols and systems like diffserv, ATM, and so on.  The other is simply to have 'too much' of the resource.  Though it feels wrong, the latter often ends up being the cheaper and easier solution.  So, for example, voice over IP is getting used quite a lot, and to good effect, on the internet today not because we have successfully deployed any bandwidth reservation or QoS management protocols and systems, but because the available bandwidth is, for the most part, greatly in excess of what is needed, and the systems can adapt in real-time to what they get (rather than asking for what they want).  The same is true for multimedia delivery;  the complexity of RTP + TCP friendliness + QoS management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed.

Fully agreed. 

Folks who like pictures can take a look at https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the same argument.

Lars

---

From: ken carlberg <[email-masked]>
Date: Tue, 9 Nov 2010 21:24:50 -0500

I would agree with Dave Singer's points below, but with significant qualifiers.  VoIP is being used more and more because significant pockets of acceptable quality can be found, but these are subject to location, and at times, time of day usage (eg, my use of Skype versus POTS varies depending on where I make my calls to Chile).  And as you get closer to the last mile (wireless and the backhaul in particular), economics do play more of a factor in how much reliance over-provisioning can solve all problems.

-ken

ps, I'm only on conex mailing list, so this will probably bounce on dispatch and httpstreaming

On Nov 9, 2010, at 9:02 PM, Lars Eggert wrote:

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

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 9 Nov 2010 21:34:33 -0500

Lars,

Thanks for sharing this post and reference.

I try to make a similar point in section 4.3 of http://tools.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt

Some operators provision sufficient capacity at bottleneck points and/or make productive use of restoration capacity so that congestion rarely occurs. A much larger potential benefit than that offered by short term congestion control occurs if a means to motivate time shifting of traffic to off-peak periods can be developed.

Thanks,

Dave

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lars Eggert [[email-masked]]
Sent: Tuesday, November 09, 2010 9:02 PM
To: David Singer
Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming; [email-masked]; [email-masked]
Subject: Re: [conex] [httpstreaming] [dispatch]   Q-HTTP

Fully agreed.

Lars

---

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

One problem with the voice analogy is that the sheer volume of data
traversing the web today is not driven by voice...it's video...and it's not
even a fraction of the viewing that folks are doing of broadcast content.  A
solution that depends on "simply" having too much bandwidth, is that someone
is paying for it.  Eventually it hits someone's pocket books....and if there
isn't sufficient revenue to cover the costs, the too much does degrade.
Today the mass media is consumed via cheap broadcast technologies... why
shouldn't the web (fixed and mobile) be as cheap AND as good??  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Lars Eggert
Sent: Tuesday, November 09, 2010 8:02 PM
To: David Singer
Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);
httpstreaming; [email-masked]; [email-masked]
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

On 2010-11-9, at 18:31, David Singer wrote:
> It is that there are two ways to solve a real-time bandwidth need.  One is
to reserve bandwidth, manage QoS and so on;  one gets protocols and systems
like diffserv, ATM, and so on.  The other is simply to have 'too much' of
the resource.  Though it feels wrong, the latter often ends up being the
cheaper and easier solution.  So, for example, voice over IP is getting used
quite a lot, and to good effect, on the internet today not because we have
successfully deployed any bandwidth reservation or QoS management protocols
and systems, but because the available bandwidth is, for the most part,
greatly in excess of what is needed, and the systems can adapt in real-time
to what they get (rather than asking for what they want).  The same is true
for multimedia delivery;  the complexity of RTP + TCP friendliness + QoS
management is not worth it compared to having adaptable end-systems and
overall more bandwidth than needed.

Fully agreed. 

Folks who like pictures can take a look at
https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the same
argument.

Lars

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Tue, 9 Nov 2010 11:17:21 +0100

Hi Ingemar

Congestion control mechanisms and exposure give operators the way to avoid problems in their networks and also reward users which does not impact on others, but does not cover the need for a quality in terms of latency and jitter, but only packet loss.

The scenario in which a particular user is paying to a content provider to ( for example) play a virtualized game, and the content provider pays to the operator in order to be possible a QoS on demand (during few minutes) for the flows from server to this particular user is the goal of Q-HTTP and although congestion must be measured, the rest of quality parameters are also important and of course the reaction time of the protocol is a key factor.

In this scenario probably this particular user is contributing to the congestion of others but should not be penalized. Conex as a form of fifferential QoS could serve this goal, but needs the help of "something like Q-HTTP" to achieve the measurements. Don't you agree?

In a philosophy perspective, we need these pieces: 
     1) a network with differential QoS capability   ( diffserv, traffic engineering, PCE, traffic mode at access node, etc)
     2) a unified measurement procedure capable to react  ( Q-HTTP ?)
     3) something to match the reactions with the QoS capability of the network ( CONEX ?)

Apart from this, in terms of overhead, Q-HTTP only uses a few Kbps, and it is configurable ( more responsiveness implies more kbps) but for example in our implementation, 15kbps is quite good for measure downstream and 1kbps for measure upstream. The responsiveness is defined at the first stage of the protocol, so can be whatever content provider wants, depending on the type of content.
 
- Jose Javier

-----Mensaje original-----
De: Ingemar Johansson S [mailto:[email-masked]] 
Enviado el: martes, 09 de noviembre de 2010 4:35
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Qin Wu; [email-masked]
CC: httpstreaming; [email-masked]
Asunto: RE: [httpstreaming] [dispatch] Q-HTTP

Hi

Regads
/Ingemar

> In addition, i have attached in this email a FAQ document for easier 
> understanding of the protocol. This document clarifies the philosophy 
> streaming on Wednesday evening, Emenrald room, which aims at  building 
> efficient transport and better QoE. One of key issues we are ready to 
> Also you can track the following link for our meeting agenda, location 
> and time:
> measurements & reactions. We believe the standardization of this topic 
> could benefit internet community in the coming years, for example for 
> virtualization of videogames through intenet. We would like to receive 
> comments and some feedback and also oppinions about the target area, 
> infrastructure Area scope, but currently the draft is in "looking for 
> an area" state
> 
>    The draft describes Q-HTTP (Quality HTTP) , which is an application 
> level protocol based on HTTP and SDP associated to a new specific uri 
> bandwidth, latency, jitter parameters, will work under current network 
> (virtualization, on line gaming, video, voice) nowadays are increasing 
> standard way of negotiating and verifying their requirements. Q-HTTP 
> reception/detection of QoS alerts exchanged by the protocol are out of

---

From: David Singer <[email-masked]>
Date: Tue, 9 Nov 2010 11:31:01 +0100

There is a bitter lesson I have learned over the years to do with QoS reservation.

(I worked on real-time scheduling systems as well, and the same applies;  it's cheaper to have a processor which is much faster than needed, with a normal scheduler, than to have a just-enough processor with a real-time scheduler).

I know, it 'feels' wrong.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Gunnar Heikkilä <[email-masked]>
Date: Tue, 9 Nov 2010 12:37:28 +0100

Hi David, Jose Javier,

for cellular networks (for instance a PC using a mobile broadband dongle) over-provisioning is really expensive and you have to do something smarter. But I am not sure that the Q-HTTP concept is the way forward since it is based on injecting test traffic into the system. 

Typically the wireless conditions can change rather fast (especially if the user is moving, say sitting on a train), so the "reaction time" based on the test traffic is most likley too long. The other problem is that the test traffic adds additional data into an already heavily loaded wireless network, which might not be easy to defend when selling this concept to the cellular operators.

But there is sure a need for good ways to handle the underlying problem you describe.

Best regards
   Gunnnar Heikkilä

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Singer
Sent: ti 9 november 2010 11:31
To: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Cc: Ingemar Johansson S; httpstreaming; [email-masked]; [email-masked]
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

David Singer

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

---

From: David Singer <[email-masked]>
Date: Tue, 9 Nov 2010 12:46:04 +0100

> for cellular networks (for instance a PC using a mobile broadband dongle) over-provisioning is really expensive and you have to do something smarter. But I am not sure that the Q-HTTP concept is th…

Right, but there is a choice of what the 'smarter' is.  (A) do some kind of QoS reservation (bandwidth reservation, maximum loss guarantee etc.) and then trust it; or (B) measure and adapt to what you're getting.

In case (A) if you are going to be resilient you should implement (B), so that if the reservation 'fails' you don't fail in turn. So you implement (B) anyway, and now the question is whether a new, special protocol for (A) is worth the trouble.  One huge downside is that it moves you away from generic servers, caches, proxies, CDNs and other existing network infrastructure.

In wireless, mobile, networks, it's hard to guarantee that the user won't move to the edge of a cell, or into a crowded cell where the reservation cannot be maintained, and so on.  Conversely, the 'cost' or availability of a reservation may well depend on the degree of competition.

David Singer

---

From: Gunnar Heikkilä <[email-masked]>
Date: Tue, 9 Nov 2010 13:04:56 +0100

Hi David,

basically I agree with your view. My main point is that using extra traffic to solve bandwidth limitations has some built-in problems. Best would be if all applications could be made elastic and adapt to whatever problem they experience (like for AMR codec daptation etc.)...

Gunnar Heikkilä
Ericsson Research 

-----Original Message-----
From: David Singer [mailto:[email-masked]] 
Sent: ti 9 november 2010 12:46
To: Gunnar Heikkilä
Cc: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Ingemar Johansson S; httpstreaming; [email-masked]; [email-masked]
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

David Singer

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 9 Nov 2010 09:37:40 -0600

David,

Video has much more volume and burstiness than VoIP, so not sure that
analogy will hold.  If you cannot be sure to have at least 50%
non-latency-sensitive traffic, and maybe more like 70%, then you will
not be over-provisioned enough to have the slack available.  And if
video is the lion's share of the traffic, then you better hope that most
of that is non-interactive.  Else, you need some type of CAC to ensure
live video doesn't get disrupted.

Separate question.  Took a quick read and it seems this Q-HTTP is a
separate flow rather than embedded attributes in the flow it is
attempting to help.  What if there is more than one flow involved?  And
how do you keep each control and app associated?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Singer
Sent: Tuesday, November 09, 2010 5:31 AM
To: GARCIA ARANDA,JOSE JAVIER (JOSE JAVIER)
Cc: Ingemar Johansson S; httpstreaming; [email-masked];
[email-masked]
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

There is a bitter lesson I have learned over the years to do with QoS
reservation.

It is that there are two ways to solve a real-time bandwidth need.  One
is to reserve bandwidth, manage QoS and so on;  one gets protocols and
systems like diffserv, ATM, and so on.  The other is simply to have 'too
much' of the resource.  Though it feels wrong, the latter often ends up
being the cheaper and easier solution.  So, for example, voice over IP
is getting used quite a lot, and to good effect, on the internet today
not because we have successfully deployed any bandwidth reservation or
QoS management protocols and systems, but because the available
bandwidth is, for the most part, greatly in excess of what is needed,
and the systems can adapt in real-time to what they get (rather than
asking for what they want).  The same is true for multimedia delivery;
the complexity of RTP + TCP friendliness + QoS management is not worth
it compared to having adaptable end-systems and overall more bandwidth
than needed.

(I worked on real-time scheduling systems as well, and the same applies;
it's cheaper to have a processor which is much faster than needed, with
a normal scheduler, than to have a just-enough processor with a
real-time scheduler).

David Singer

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Tue, 9 Nov 2010 18:27:36 +0100

Hi Mike and all

Q-HTTP uses a separate control flow for measurements, as you mention, and the application could have N flows. 

When Q-HTTP monitor the quality, it monitors at the "QoS level" of the application flows and alert if constraints are being violated.
If the application has other "non quality" flows, these are not in the scope of Q-HTTP.

Q-HTTP is designed to monitor a set of flows simultaneously (in forward and reverse directions) with different constraints and sensitiveness in each direction. The flows are grouped by constraints, so the same Q-HTTP control flow monitor two sets of flows at the same time:

- a set of downstream flows with the same constraints
- a set of upstream flows with the same constraints ( different from downstream constraints)

The constraints in the same Q-HTTP control flow are defined for up and down sepparately, so the same control flow can have different constraints for up and down, and also different responsiveness (different kbps usage by the control flow in up and down)

The underlaying idea is to allow monitor the quality of any application data protocol used ( simple data over UDP or TCP, ftp, rtp, http, propietary, etc etc), in order to be able to provide a universal measurement/alerting mechanism for any communication at application level.

And...when the alert is raised, what to do? Well, there are a lot of options, for example reduce bitrate of app data flows, or limit the functionalies of the application, or the server can invoke a operator QoS service asking for more quality, or invoke a multi-operator entity which acts over the policy servers of the different operators, or also the network itself could be Q-HTTP aware and react by itself when an alert is raised... All these possibilities are open, and not defined in the draft, but all of them are possibilities

- Jose Javier

-----Mensaje original-----
De: Mike Hammer (hmmr) [mailto:[email-masked]] 
Enviado el: martes, 09 de noviembre de 2010 16:38
Para: David Singer; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: Ingemar Johansson S; httpstreaming; [email-masked]; [email-masked]
Asunto: RE: [dispatch] [httpstreaming] Q-HTTP

David,

Video has much more volume and burstiness than VoIP, so not sure that analogy will hold.  If you cannot be sure to have at least 50% non-latency-sensitive traffic, and maybe more like 70%, then you will not be over-provisioned enough to have the slack available.  And if video is the lion's share of the traffic, then you better hope that most of that is non-interactive.  Else, you need some type of CAC to ensure live video doesn't get disrupted.

Separate question.  Took a quick read and it seems this Q-HTTP is a separate flow rather than embedded attributes in the flow it is attempting to help.  What if there is more than one flow involved?  And how do you keep each control and app associated?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Singer
Sent: Tuesday, November 09, 2010 5:31 AM
To: GARCIA ARANDA,JOSE JAVIER (JOSE JAVIER)
Cc: Ingemar Johansson S; httpstreaming; [email-masked]; [email-masked]
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

David Singer

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 09 Nov 2010 17:22:44 -0600

+1
Fully agree.

Thanks, Henry

On 11/9/10 4:31 AM, "David Singer" <[email-masked]> wrote:

> It is that there are two ways to solve a real-time bandwidth need.  One is to
> reserve bandwidth, manage QoS and so on;  one gets protocols and systems like
> diffserv, ATM, and so on.  The other is simply to have 'too much' of the
> resource.  Though it feels wrong, the latter often ends up being the cheaper
> and easier solution.  So, for example, voice over IP is getting used quite a
> lot, and to good effect, on the internet today not because we have
> greatly in excess of what is needed, and the systems can adapt in real-time to
> what they get (rather than asking for what they want).  The same is true for
> multimedia delivery;  the complexity of RTP + TCP friendliness + QoS
> (I worked on real-time scheduling systems as well, and the same applies;  it's
> cheaper to have a processor which is much faster than needed, with a normal
> scheduler, than to have a just-enough processor with a real-time scheduler).
>

---

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

Sent from my iPad

> shouldn't the web (fixed and mobile) be as cheap AND as good??  

It should, the question is what is the cheapest way to do it. QoS is expensive too. I tend to agree with the thesis below that history is telling us that avoiding scarcity in the first place is cheaper than rationing here.

...Mark

---

From: Roland Bless <[email-masked]>
Date: Wed, 10 Nov 2010 09:11:30 +0100

Hi David,

On 09.11.2010 11:31, David Singer wrote:

> It is that there are two ways to solve a real-time bandwidth need.
> One is to reserve bandwidth, manage QoS and so on;  one gets
> protocols and systems like diffserv, ATM, and so on.  The other is
> simply to have 'too much' of the resource.  Though it feels wrong,

QoS mechanisms are usually only necessary if you've got some kind of
resource shortage. They try to manage the resource scarcity in some
way then. So having "too much of a resource" seems to imply that we
actually don't need any QoS support.

The basic problem is that even if you over-provision you'll depend
on the traffic distribution (i.e. the traffic matrix). For instance,
if you've got 10x100Mbit/s links aggregated to a 1 Gbit/s "upstream"
link, you usually have no problem of transmitting traffic towards the
larger link. In the other direction though, it depends heavily on the
incoming
traffic distribution. So if the 1 Gbit/s link transmits 200 Mbit/s
towards a single 100Mbit/s link over a longer period, you'll get dropped
packets. Denial-of-Service attacks can achieve this effect
intentionally. It's no problem using my PC and trying to flood several
DSL subscriber lines, or using 10 PCs at our campus site and trying to
flood some link with the aggregated bandwidth of ~ 10 Gbit/s. Your
real-time traffic will definitely suffer then...

I fear that the bandwidth demand will increase a lot due to HD streaming
etc. and that we need some kind of active QoS management at the edge
or access networks at least.

> the latter often ends up being the cheaper and easier solution.  So,

Yes, but not a really reliable solution and it works only as long as
the fair/whatever resource share is enough to provide the minimum
acceptable quality.

> The same is true for multimedia delivery;  the complexity of RTP +
> TCP friendliness + QoS management is not worth it compared to having
> adaptable end-systems and overall more bandwidth than needed.

I agree that having adaptable applications is a good idea anyway
and that QoS management adds a lot of complexity (and also complexity
at SLA level).

> (I worked on real-time scheduling systems as well, and the same
> applies;  it's cheaper to have a processor which is much faster than
> needed, with a normal scheduler, than to have a just-enough processor
> with a real-time scheduler).

> I know, it 'feels' wrong.

I think it's fine as long as everything behaves somehow friendly,
i.e., in the absence of DoS flooding attacks...

Regards,
 Roland

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 10 Nov 2010 09:14:39 +0100

Hi

I see congestion and delay as two sides of the same coin. I believe that some of the good to do's in Lars slides mentioned the use of AQM and avoid long buffers. This of course assumes that applications are responsive to congetsion signals (packet drops, ECN..) within a few RTTs. If that holds true then the aggregate traffic in a bottleneck will not load the network beyond the point where delay gets high (or packet losses increases daramatically)

/Ingemar

> Sent: den 10 november 2010 15:25
> To: Mark Watson; Kathy McEwen
> Cc: Lars Eggert; David Singer; Ingemar Johansson S; 
> Adaptable non-interactive video delivery is suitable for 
> congestion problems, but what about latency?
> It is no possible to adapt to a large latency reducing video 
> resolution.
> 
> I refer to the "interactive video" scenario, for example a 
> virtualized videogame.
> Video must be delivered to the final user quickly and final 
> user press action controls which change the video in 
> real-time. If final user wants to play to "Street fighter" in 
> a videoconsole located in the cloud, it is needed a mechanism 
> for Measuring and adjust latency, in both directions.
> 
> Even with overall more bandwidth than needed, the problem persists.
> 
> - Jose Javier
> 
> 
> De: Mark Watson [mailto:[email-masked]] Enviado el: 
> miércoles, 10 de noviembre de 2010 5:19
> Para: Kathy McEwen
> CC: Lars Eggert; David Singer; Ingemar Johansson S; GARCIA 
> ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming; 
> [email-masked]; [email-masked]
> Asunto: Re: [httpstreaming] [dispatch] Q-HTTP
> 
> 
> 
> Sent from my iPad
> 
> > traversing the web today is not driven by voice...it's video...and 
> > it's not even a fraction of the viewing that folks are doing of 
> > broadcast content.  A solution that depends on "simply" having too 
> > much bandwidth, is that someone is paying for it.  
> Eventually it hits 
> > someone's pocket books....and if there isn't sufficient 
> revenue to cover the costs, the too much does degrade.
> > Today the mass media is consumed via cheap broadcast 
> technologies... 
> > why shouldn't the web (fixed and mobile) be as cheap AND as good??
> > 
> 
> It should, the question is what is the cheapest way to do it. 
> QoS is expensive too. I tend to agree with the thesis below 
> that history is telling us that avoiding scarcity in the 
> first place is cheaper than rationing here.
> 
> ...Mark
> 
> >> One is
> > to reserve bandwidth, manage QoS and so on;  one gets protocols and 
> > systems like diffserv, ATM, and so on.  The other is simply to have 
> > 'too much' of the resource.  Though it feels wrong, the 
> latter often 
> > ends up being the cheaper and easier solution.  So, for 
> example, voice 
> > over IP is getting used quite a lot, and to good effect, on the 
> > internet today not because we have successfully deployed 
> any bandwidth 
> > reservation or QoS management protocols and systems, but 
> because the 
> > available bandwidth is, for the most part, greatly in 
> excess of what 
> > is needed, and the systems can adapt in real-time to what they get 
> > (rather than asking for what they want).  The same is true for 
> > management is not worth it compared to having adaptable 
> end-systems and overall more bandwidth than needed.
> > 
> > Fully agreed. 
> > 
> > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much 
> > the same argument.
> > 
> > Lars
> >

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 10 Nov 2010 11:00:45 +0000

Hi,

Agree to Ingemar's view -- congestion and queuing delay are closely related. The "QoS by over-provisioning" argument is however only half-true, because there are networking domains, such as wireless mobile (as already mentioned here), where capacity demand is dynamic, resources are assigned dynamically, depending on different factors, and some capacity scarcity can still be expected even in future networks.

But independent of that, for the virtualized video game, I don't think you are actually interested in measuring/adjusting latency as long as there are AQM *and* good enough incentives for other applications to yield to your important, bursty video game traffic within a few RTTs.

Such incentives for adapting your sending behavior can apply to both transport and application layer behavior, i.e., congestion indication would trigger codec/format parameter switching. There are interesting questions on the time scale of such adaptations, i.e., in relation to transport layer response to congestion.

Best regards,

Dirk

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ingemar Johansson S
> Sent: Wednesday, November 10, 2010 9:15 AM
> To: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Mark Watson; Kathy McEwen
> Cc: httpstreaming; [email-masked]; David Singer; [email-masked]
> I see congestion and delay as two sides of the same coin. I believe
> that some of the good to do's in Lars slides mentioned the use of AQM
> and avoid long buffers. This of course assumes that applications are
> responsive to congetsion signals (packet drops, ECN..) within a few
> RTTs. If that holds true then the aggregate traffic in a bottleneck
> will not load the network beyond the point where delay gets high (or
> packet losses increases daramatically)
> 
> /Ingemar
> 
> 
> 
>

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Wed, 10 Nov 2010 08:25:05 +0100

Adaptable non-interactive video delivery is suitable for congestion problems, but what about latency?
It is no possible to adapt to a large latency reducing video resolution.

I refer to the "interactive video" scenario, for example a virtualized videogame.
Video must be delivered to the final user quickly and final user press 
action controls which change the video in real-time. If final user wants to play to
"Street fighter" in a videoconsole located in the cloud, it is needed a mechanism for
Measuring and adjust latency, in both directions.

- Jose Javier

-----Mensaje original-----
De: Mark Watson [mailto:[email-masked]] 
Enviado el: miércoles, 10 de noviembre de 2010 5:19
Para: Kathy McEwen
CC: Lars Eggert; David Singer; Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming; [email-masked]; [email-masked]
Asunto: Re: [httpstreaming] [dispatch] Q-HTTP

Sent from my iPad

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

> much bandwidth, is that someone is paying for it.  Eventually it hits 
> someone's pocket books....and if there isn't sufficient revenue to cover the costs, the too much does degrade.
> Today the mass media is consumed via cheap broadcast technologies... 

...Mark

> 'too much' of the resource.  Though it feels wrong, the latter often 
> ends up being the cheaper and easier solution.  So, for example, voice 
> internet today not because we have successfully deployed any bandwidth 
> reservation or QoS management protocols and systems, but because the 
> available bandwidth is, for the most part, greatly in excess of what 
> management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed.
> 
> Fully agreed. 
>

---

From: David Singer <[email-masked]>
Date: Wed, 10 Nov 2010 14:01:40 +0100

Hi Roland,

> actually don't need any QoS support.

I think this raises a question that happens at a service provider.  Imagine I observe that my networks are getting more busy, and decide to invest some more in them.  Do I (a) deploy a QoS management infrastructure or (b) use those same funds to pay for capacity upgrades?  I think that most operators end up choosing (b) as it 'lifts all boats', whereas they are not confident that anyone will use (a) in the near future, and they know it won't benefit everyone (and in fact, will be to the detriment of some users who don't use it, and were previously doing 'fair competition' for bandwidth and now are 'second class' behind those with reserved bandwidth).

David Singer

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Wed, 10 Nov 2010 14:27:15 +0100

Hi David,

In the end, SPs are driven by costs and revenus. Does option (a) represent the same cost as (b)? (I do not know..)

-How will the investment be paid  back in case of (a).. Raising subscription fees for everyone? Will that not lead to enhanced subscriber churn? Is net revenu then positive for the SP?

-How will the investment be paid back in case of (b)... Those subscribers that want 1st class service will be willing to pay extra for it. Other that won't, will probably sense they get a smaller piece of the bandwidth pie, and may decide to change SP. What is net revenu here?

My impression is that it is not immediately clear whether (a) or (b) or any mix of (a) and (b) is the best strategy for a SP.

Regards
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Singer
Sent: woensdag 10 november 2010 14:02
To: Roland Bless
Cc: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Subject: Re: [httpstreaming] [conex] [dispatch] Q-HTTP

Hi Roland,

David Singer

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 10 Nov 2010 09:05:01 -0600

Nice theory.  Until it gets down to who is going to pay for the
over-provisioning.

Is the ARPU going to go up?  Are content distributors willing to pay
more to send that data?

Also, note how the volume of traffic always seems to expand to fill the
BW available.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Watson
Sent: Tuesday, November 09, 2010 11:19 PM
To: Kathy McEwen
Cc: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson
S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER)
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

Sent from my iPad

> traversing the web today is not driven by voice...it's video...and
it's not
> Today the mass media is consumed via cheap broadcast technologies...
why
> shouldn't the web (fixed and mobile) be as cheap AND as good??  

It should, the question is what is the cheapest way to do it. QoS is
expensive too. I tend to agree with the thesis below that history is
telling us that avoiding scarcity in the first place is cheaper than
rationing here.

...Mark

One is
> to reserve bandwidth, manage QoS and so on;  one gets protocols and
systems
> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much
the same

---

From: David Singer <[email-masked]>
Date: Wed, 10 Nov 2010 16:24:52 +0100

> Nice theory.  Until it gets down to who is going to pay for the

Well, it's a nice theory until someone asks who is going to (a) pay for the QoS management infrastructure and (b) pay for the QoS managed traffic.

David Singer

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 10 Nov 2010 10:07:26 -0600

My problem is that the alternative solution proposes that:

1) Users will police themselves and degrade their experience for the
good of the Internet, and
2) Somehow high-BW bursty applications will become non-bursty.
3) The people that build and operate the networks will double
(quadruple?) their investments for no additional return out of the
goodness of their hearts.

Somehow this reminds me of Gates prognostication that 640K was all the
memory that a PC would ever need.

I'm sympathetic with having a simple answer, but I just haven't seen
that happen in the last 30 years.

Don't forget that for some time we have had QoS managed and paid for.  
The burden of proof then lies in proving the new economic model works.
Good luck.  I will be the first to congratulate you if you do.

Cheers,
Mike

-----Original Message-----
From: David Singer [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2010 10:25 AM
To: Mike Hammer (hmmr)
Cc: Mark Watson; Kathy McEwen; [email-masked]; httpstreaming;
[email-masked]; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA,
JOSEJAVIER (JOSE JAVIER)
Subject: Re: [dispatch] [httpstreaming] Q-HTTP

> Nice theory.  Until it gets down to who is going to pay for the

Well, it's a nice theory until someone asks who is going to (a) pay for
the QoS management infrastructure and (b) pay for the QoS managed
traffic.

>> is paying for it.  Eventually it hits someone's pocket books....and
if
> there
>> like diffserv, ATM, and so on.  The other is simply to have 'too
much'
> of
>> to what they get (rather than asking for what they want).  The same
is
> true

David Singer

---

From: David Singer <[email-masked]>
Date: Wed, 10 Nov 2010 17:27:21 +0100

Mike

I'm not sure what you consider to be the primary model and what is the alternative.  Just in case we don't understand each other, I'll lay out where I think we are.

At the moment, we don't have QoS management, and HTTP streaming uses HTTP, which rests on TCP.  Applications don't "degrade themselves", they get degraded when contention happens, as a result of TCP's flow management, and have to cope.  It's a 'fair' system in that respect (especially when contrasted with RTP blast-and-hope).

In a QoS-managed scenario, something 'allows' me to indicate that a flow 'deserves' or 'needs' a certain QoS, including bandwidth, and then (if granted) I become immune to cross-traffic.  

For example, if all flows are equal, and initially there were 5 of which 2 are QoS managed, and they request only 10% of the resource, we're in great shape;  they get 20% and the 3 remaining share the remainder 60%, for 20% each.  But now 7 new flows come along, not QoS managed, so there are now 10 flows sharing that 60% for only 6% each, while the QoS-managed ones get 10% -- no longer fair.  If there isn't some disincentive to QoS-book bandwidth (like having to pay) we'll all set up the biggest channels we can.  If we *do* have to pay, the complexity of the QoS management is now increased -- not only handling the technical booking and reservation, segregation of packet flows, and so on, but it has a billing infrastructure too.

Then, in the case of QoS management, the service is probably only as strong as its weakest link.  Some QoS management protocols either set up an end-to-end QoS-managed flow (across potentially multiple providers) or they fail.  This doesn't allow for easy service introduction.  Alternatively, they manage only some of the links, and then the QoS-booking becomes rather weak if the unmanaged link is the bottleneck.

Then there is the question of who sets up and who pays.  Imagine I (in california) try to watch a BBC video (from the UK).  It's me that needs to pay, but the BBC that needs to indicate to the service what pipe and QoS are needed to deliver their content.  Then all the business between me and them need to work out if they can do that QoS, and at what cost; someone needs to ask me if I am willing to pay, and if I agree, tell the BBC to setup the pipe, and off we go.  Contrast this with today where the BBC is careful not to use too much of its outbound pipe for one customer, and I buy the pipe I want, and each organization in the middle sells 'uplink' bandwidth.  That's a 'static' business arrangement.

David Singer

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Wed, 10 Nov 2010 18:13:54 +0100

Hi,
   Just my 2 cents on this...

    At the moment, some services are just not flying because of this "fairness" on Internet...My personal opinion is that this is going to end (just hear the loud voices of Network operators like Telefonica claiming that Google needs to pay them for the service they provide). With this in mind, we must assume that the end-customer will pay for such "new-age" services (Google VoD, Online Gaming, Virtualized Gaming or something we cant even think about) to the service provider (Google, Game provider...). This service provider will pay network operator to provide the service to the end user with a minimum quality of experience (this is inline with network operators thoughts). Thus, Tier-1 providers will need to evolve their model from a "per-bit" schema to a "per-bit-per-QoS" one. With all this in mind, we need the tools to:

- Provide the flow requirements. Not all the services require the same parameters from the network
- A way to measure those parameters e2e.
- A way to "cry for help" if those parameters are below (or critically close) the limits
- A way to account for this. You ask for QoS, you pay for that. Once we forget fairness, we forget the flat-rate and change it to "pay for experience".

    Q-HTTP tries to answer this questions. We know this is not simple as involves many other actions (billing, modifying network QoS, multi-tier agreements, etc) but lets start work it out now :).

    Saludos,
         Luismi

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de David Singer
Enviado el: miércoles, 10 de noviembre de 2010 17:27
Para: Mike Hammer (hmmr)
CC: [email-masked]; Kathy McEwen; httpstreaming; [email-masked]; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: Re: [dispatch] [httpstreaming] Q-HTTP

Mike

On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote:

> Well, it's a nice theory until someone asks who is going to (a) pay 
> for the QoS management infrastructure and (b) pay for the QoS managed 
> traffic.
> 
>> 
>>> quite a lot, and to good effect, on the internet today not because 
>>> we
>> have

David Singer

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 10 Nov 2010 12:26:47 -0600

David,

It is possible we have different usage scenarios in mind and could be
talking past one another.  There are lots of variables.  Is this
unicast, multicast, broadcast, full-duplex, interactive, mixtures of
high and low BW, latency-sensitive and not, very bursty and not, where
the sources of content are, how many sources, P2P or not, etc.  And all
of these dynamically interact on the network.  Some subset of
applications may be able to play nicely on a BE network.  But, I am just
being cautions to not extrapolate that to all applications.  In some
cases, the QoS may be worth the management and cost proportional to its
usage.  So, maybe this is just an issue of scoping the application of
the solution to the subset of traffic known to behave well.

Mike

-----Original Message-----
From: David Singer [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2010 11:27 AM
To: Mike Hammer (hmmr)
Cc: Mark Watson; Kathy McEwen; [email-masked]; httpstreaming;

Mike

I'm not sure what you consider to be the primary model and what is the
alternative.  Just in case we don't understand each other, I'll lay out
where I think we are.

At the moment, we don't have QoS management, and HTTP streaming uses
HTTP, which rests on TCP.  Applications don't "degrade themselves", they
get degraded when contention happens, as a result of TCP's flow
management, and have to cope.  It's a 'fair' system in that respect
(especially when contrasted with RTP blast-and-hope).

In a QoS-managed scenario, something 'allows' me to indicate that a flow
'deserves' or 'needs' a certain QoS, including bandwidth, and then (if
granted) I become immune to cross-traffic.  

For example, if all flows are equal, and initially there were 5 of which
2 are QoS managed, and they request only 10% of the resource, we're in
great shape;  they get 20% and the 3 remaining share the remainder 60%,
for 20% each.  But now 7 new flows come along, not QoS managed, so there
are now 10 flows sharing that 60% for only 6% each, while the
QoS-managed ones get 10% -- no longer fair.  If there isn't some
disincentive to QoS-book bandwidth (like having to pay) we'll all set up
the biggest channels we can.  If we *do* have to pay, the complexity of
the QoS management is now increased -- not only handling the technical
booking and reservation, segregation of packet flows, and so on, but it
has a billing infrastructure too.

Then, in the case of QoS management, the service is probably only as
strong as its weakest link.  Some QoS management protocols either set up
an end-to-end QoS-managed flow (across potentially multiple providers)
or they fail.  This doesn't allow for easy service introduction.
Alternatively, they manage only some of the links, and then the
QoS-booking becomes rather weak if the unmanaged link is the bottleneck.

Then there is the question of who sets up and who pays.  Imagine I (in
california) try to watch a BBC video (from the UK).  It's me that needs
to pay, but the BBC that needs to indicate to the service what pipe and
QoS are needed to deliver their content.  Then all the business between
me and them need to work out if they can do that QoS, and at what cost;
someone needs to ask me if I am willing to pay, and if I agree, tell the
BBC to setup the pipe, and off we go.  Contrast this with today where
the BBC is careful not to use too much of its outbound pipe for one
customer, and I buy the pipe I want, and each organization in the middle
sells 'uplink' bandwidth.  That's a 'static' business arrangement.

> Well, it's a nice theory until someone asks who is going to (a) pay
for
we

David Singer

---

From: Kathy McEwen <[email-masked]>
Date: Wed, 10 Nov 2010 10:36:09 -0800

A scope that limits applications to only those that behave well seems extremely limiting.  What would you categorize as well behaved and naughty? 

Me, I tend to go for the naughty...

Sent from my iPhone

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 Nov 2010 23:08:25 +0100 (CET)

> goodness of their hearts.

No, they're going to do it because if they don't give the customers what 
they promised, their customers are going to leave. This is if there is a 
functional market and customers actually have a choice of providers. I 
realise this is not the case in parts of the world, but that doesn't mean 
we should solve that by technical means, that's a political and regulatory 
problem, it doesn't have any technical solution.

Let's not forget that if you're congesting your core and distribution, 
you're not delivering what your customers have purchased. Period.

Everything else is just smoke and mirrors.

Congestion is acceptable on the customer access, it's not acceptable in 
the core. That means that any flows/pakets that should yield, are within a 
single customer domain, and thus in the customers own interest.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 16:32:08 +0100 (CET)

On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote:

> So, you are assuming that the alternative provider is not subject to the 
> same economic constraints as the provider you are jumping from?  If that 
> were such an easy thing to do, you would see many more players on the 
> field, and fewer commentators in the stands.

In my market there are lots of players and they all have possibility to 
reach end users because there are "neutral" L1 providers to rent 
fiber/copper from. Competition works, and it stops aggregation congestion.

> Agree, that the core should not be getting congested, but this problem 
> gets worse progressively as you approach the customer edge.  And the 
> costs to overprovision the edge go up correspondingly.  The last mile is 
> the most expensive.

The customer unique connection is ok to congest, it's running at the speed 
the customer is paying for. It's everything up from that that should 
"never" be congested, because then you're not giving the customer what 
they're paying for. It's a breach of contract, pure and simple. You're 
free to statistically overbook your aggregation up to the point where it's 
extremely rarely congesting.

Would you accept a telephony network that gave you no dialtone half of the 
time you tried? I don't get it. Why would ISPs get away with not 
delivering what they have sold and why should we help them do this?

What the IETF and everybody should focus on is SHOWING to the end users 
that there is congestion occuring, so they have a tool to give their 
consumer protection agency this informaiton to demand to cancel their 
contract because their ISP is not delivering on its promise.

This works in all other markets, there false advertising is not tolerated, 
why should it be in the ISP market? If you're buying 100 megabit/s of 
residential bw you should be able to use this speed at least 99% of the 
time, otherwise your ISP is overselling the resource and you're not 
getting what you have bought. If the ISP has gigabit aggregation it's most 
likely that they can get away with 1000 users or more on this gige at this 
speed, but they will not get away with it by doing 200 meg aggregation.

People talk about "fair". Fair business practice is to deliver what you've 
sold. Fair is to treat every customers traffic equally, to deliver the 
packets they want delivered. That is the job of the ISP. It's not to 
mistreat some traffic or discriminate. If anything, THAT is the unfair 
part.

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2010 5:08 PM
> To: Mike Hammer (hmmr)
> Cc: David Singer; [email-masked]; Kathy McEwen; httpstreaming;
> [email-masked]; Ingemar Johansson S; Mark Watson; GARCIA ARANDA,
> JOSEJAVIER (JOSE JAVIER)
> Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP
>

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:55:01 +0100

I fully agree with Paul Kyzivat and Luis miguel, in summary:

- the contractual obligations of operators are very "light" "up to NNN bps".
- these "light" obligations allow a low flat fee but not allow quality services
- "new age services" needs QoS, and final user will pay for that service to the content provider
- content provider will pay network operator to provide the service to the end user with a minimum quality of experience
- Tier-1 providers will need to evolve their model from a "per-bit" schema to a "per-bit-per-QoS" one

As Luis Miguel said, we need the tools (Q-HTTP can be) to:

- Provide the flow requirements. Not all the services require the same parameters from the network
- A way to measure those parameters e2e.
- A way to "cry for help" if those parameters are below (or critically close) the limits
- A way to account for this. Content provider ask for QoS, and would pay for that. 

Other scenarios in which the final user pays for QoS are possible, but in general terms, i believe that Content provider is who is going to pay for that, not final user, which pays the "flat fee" for a best-effort internet access

-Jose Javier

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 09:01:03 +0100 (CET)

> - the contractual obligations of operators are very "light" "up to NNN bps".

In my market the consumer rights entity has worked with ISPs and gotten 
rid of that. It's not "between X and Y megabit/s as per this test-tool". 
If the ISP doesn't provide this, the customer has the right to cancel the 
contract.

> - these "light" obligations allow a low flat fee but not allow quality services

We have lower flat fees that in most markets, this is due to actual 
competition in the market. We also generally don't have any congestion in 
the ISP network, only on access.

> - Tier-1 providers will need to evolve their model from a "per-bit" schema to a "per-bit-per-QoS" one

I strongly disagree. The Internet was successful because of "bill and 
keep". Let's not kill what has been a huge success.

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Thu, 11 Nov 2010 11:28:58 +0100

In line.... 

    Saludos,
         Luismi

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Mikael Abrahamsson
Enviado el: jueves, 11 de noviembre de 2010 9:01
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S; Kathy McEwen
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

> - the contractual obligations of operators are very "light" "up to NNN bps".

In my market the consumer rights entity has worked with ISPs and gotten rid of that. It's not "between X and Y megabit/s as per this test-tool". 
If the ISP doesn't provide this, the customer has the right to cancel the contract.

[[Luismi]]: You are very lucky :). This is not the standard in most part of the world.

> - these "light" obligations allow a low flat fee but not allow quality 

We have lower flat fees that in most markets, this is due to actual competition in the market. We also generally don't have any congestion in the ISP network, only on access.

[[Luismi]]: Congestion on access is also a big problem. Q-HTTP provides end-to-end checking of compliance of SLA, and if network is violating that (no matter where) Q-HTTP will inform "someone" of the violation. After that, several options are possible (for instance, ACP can recode video to a lower bit-rate in order to fit in) and that specific flow can get higher priority (only on access or in the whole network) to avoid congestion. We are not taking about HOW we can do that, first of all we need the tools to detect WHEN we need to do the magic....

> - content provider will pay network operator to provide the service to 
> the end user with a minimum quality of experience

I strongly disagree. The Internet was successful because of "bill and keep". Let's not kill what has been a huge success.

[[Luismi]]: We are not killing, we are evolving. Bill and keep was nice when network usage was fair, since the only services available where much alike. Today, comparing emailing or web surfing with video on demand or online gaming (and beyond, with virtualized services) is not fair anymore, so we need to evolve Internet to a non-fair world.

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 11 Nov 2010 10:52:40 -0000

> Of Mikael Abrahamsson
> Sent: 10 November 2010 22:08
> To: Mike Hammer (hmmr)
> S; Kathy McEwen; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER); Mark Watson;
> David Singer
> they promised, their customers are going to leave. 

And what about if the customer signed up to a 12 months contract?

>This is if there is
> a

It is really hard to ignore the lack of proper competition. In the ideal
world there would be a perfect market, a large selection of providers, no
artificial barriers to changing provider and all users would behave in a
perfect rational economic manner. Then price would be driven down towards
cost and providers would have to invest in upgrade capacity.

> you're not delivering what your customers have purchased. Period.

But let's also not forget that TCP is designed to fill available BW, and
versions such as CUBIC are getting pretty good at that. Given the rapid
increase in access speed, the required level of over-provisioning in the
core is going to become ridiculous.

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 11 Nov 2010 08:50:41 -0600

Mikael,

Mike

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, November 10, 2010 5:08 PM
To: Mike Hammer (hmmr)
Cc: David Singer; [email-masked]; Kathy McEwen; httpstreaming;

functional market and customers actually have a choice of providers. I 
realise this is not the case in parts of the world, but that doesn't
mean 
we should solve that by technical means, that's a political and
regulatory 
problem, it doesn't have any technical solution.

Congestion is acceptable on the customer access, it's not acceptable in 
the core. That means that any flows/pakets that should yield, are within
a 
single customer domain, and thus in the customers own interest.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 18:15:30 +0100 (CET)

On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote:

> I think the crux of our disagreement here is the difference between what 
> it takes to be an ISP and what it takes to be an access provider.  The 
> economics are different.  Apples and oranges.  Saying it works for 
> oranges means it makes sense for apples is a non-sequitor.

For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs 
own L1 as well. What do you mean by it?

> <Start political view>
> It is nice that you have a regulated monopoly of L1 in your market, but

It's not a monopoly. Well, the copper is mostly, but the fiber isn't.

> However, comparing blocking (dial-tone means nothing, busy signal does)
> of QoS guaranteed telephone links with non-QoS based congestion is
> self-contradictory.  You are in essence saying that on the one hand
> providers should not have the tools to provide QoS guarantees and on the
> other hand slapping them for not being able to provide a QoS guarantee.
> Now how fair is that?

I don't want QoS guarantees, I want *all* my packets delivered, 
expediently, regardless if my neighbour is filling up his pipe or not. I 
have paid for it, and I want it DELIVERED. The postal office doesn't get 
to choose which of my letters it's ok to delay or throw away, they should 
just deliver them. Same with my ISP.

> I would not be so quick to deride the advertizing as false as not very 
> clear, but I do think there could be better education of the public. 
> (Have you never tried to explain this to a non-techie and watched their 
> eyes glaze over?)

That's why the IETF should work on tools to show this to people, not give 
ISPs tools to screw their customers.

> As for treating traffic equally, you apparently don't care much about
> real-time interactive applications.  That is your choice.  But, please
> don't impose that on everyone.

I am fine with packet prioritization within my access line. I have AQM on 
my own access line, because it makes my access line perform better for my 
packet mix (prioritizes my VoIP and ssh before my data heavy TCP 
sessions).

The problem I'm having here is that most talk is not about how to make the 
customers access line behave better for the customer, it's to have certain 
customers traffic be lower prioritized in the distribution and core, so 
ISPs can oversubscribe more without customers being able to notice too 
much.

I resent that.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 18:53:07 +0100 (CET)

On Thu, 11 Nov 2010, David Singer wrote:

> It's interesting you say this in the context of real-time media, because 
> I believe a network can give time guarantees ("any packet I deliver on 
> this will be delivered within x ms") or delivery guarantees ("all 
> packets will eventually be delivered") but it's hard (impossible, maybe) 
> to do both.

Are we talking 100.000% or 99.5% ? With cheap residential broadband, I 
want the norm to be that the ISP is not congesting their 
core/distribution. I don't want formal guarantees, I just want the normal 
mode to be that I can use my full access bandwidth, regardless of what 
application I'm running. With flash events, both telephony and packet 
networks can't handle peak load, but this doesn't happen every day, it's 
"few times per year" events.

> Personally, I want my fair share of the shared 'roads' no matter how 
> many others are sharing them, and I expect the 'last mile' personal link 
> to have (at least) the capacity that was sold to me.

And what is "fair"? I want my access link to be the limiting factor, not 
my ISP distribution/core/peering links. I was sold X megabit/s "Internet 
Access". I want that.

I don't want "X megabit/s Internet Access unless it's that time of day 
when most people want to use the Internet, then you get much less but we 
won't state how much less, and oh by the way, you'll get different amount 
depending on what L3/L4 information you provide to us in your packets".

Let's work on empowering the users so they can understand when their 
internet supplier is not giving them what they paid for. The users need 
tools, the ISP doesn't. The ISP can look at their mrtg graphs showing 
octets in and out, and if the 5 minute average utilization of their link 
is over ~75-85% or so, they're most likely not doing their job right.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 19:56:05 +0100 (CET)

On Thu, 11 Nov 2010, Kathy McEwen wrote:

> deploying additional capacity at the problem indefinitely. Policy management
> is emerging as a potential tool to get more capacity out of installed
> networks. Network policies are rules that are defined by the service

How would policy management get more *capacity* out of installed networks?

The only thing it can do is to perhaps increase the customer interactive 
experience of the network, but it doesn't increase capacity.

No matter how much you squeeze a dry stone, it's still dry. A network that 
is full is full, regardless how you prioritize traffic.

Also, I don't agree at all with the world reality the text describes. it 
might the writers reality, but it's not mine.

I'd rather build out more capacity with cheap fast simple equipment that 
moves packets without much intelligence, than to have more expensive 
complicated equipment that is slower but has more intelligence to 
"optimize" things.

10GE pricing is dropping each year, we have 100G(E) around the corner, 
networks can be built out, we have the technology.

Best effort is fine if ISPs actually make it *best* effort, and not 
mediocre or half-baked effort.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 20:01:43 +0100 (CET)

On Thu, 11 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

>   Just a different approach. Think in a traffic jam. I know it would be 
> nice to live in a wonderful world with no jams, but they happen. Know 
> compare you, going back home from work, and an ambulance with someone 
> dying inside. Everybody gets away to let ambulance drive first. And 
> that's OK.

When there is a traffic jam due to an accident it's ok. Where there is LA 
style traffic jams 12 hours of the day, that's not ok.

>   Now think on Internet. You are playing a Real-Time game and your 
> neighbours are just downloading files. They can afford some amount of 
> traffic loss (+delay/jitter) since TCP retransmisions will do the trick 
> (just will take a little longer to get the job done) while you cannot 
> afford losing (+delaying/jitterin) your traffic because if it happens, 
> your opponent will blow you away from the arena. That's the point, all 
> traffic flows are NOT the same and need different SLAs.

It would help the customer to get different treatment of his/her flows on 
the access. It would help the ISP and not the customer to do the same in 
the distribution/core. Who do we want to help? Is it the end user or is it 
the ISP? In the discussions in CONEX I mostly see people wanting to help 
the ISP, not the end user.

> - Enables network operators to generate more revenue for 
> "over-requirements". I dont think real-time was in mind whe Internet was 
> created and we need to provide ISPs with new tools like this.

"over-requirement" as in "I want to actually get what you promised to 
deliver to me"?

I don't buy it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 21:44:24 +0100 (CET)

On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

> Service providers are worried about ARPU. It is decreasing becasue the 
> "exaflood" phenomenon. The exponential traffic can not be sustained by 
> the network, with incremental increases in bandwidth.

I don't get it. Are you saying that because there is more traffic, the 
user is paying less money per month? Yes, profit per customer might be 
down, but why should traffic volume decrease revenue?

> These ISP capabilities can be priced to developers/content providers, increasing
> ISP revenues. Capabilities such as location, presence, billing, security, QoS....

I agree that an ISP can be a micropayment provider and also provice some 
location information.

> One of the most important is QoS. If developers can not find profitable 
> business Models, innovation is compromised. QoS means a mix of traffic 
> engineering + priorization + etc

Packet prioritization is only of value when the network is full. QoS is 
only of interest when BE works badly.

> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to enable virtualization of games
> (like www.onlive.com, but using the network instead locating servers at last mille)

I don't get this either. You can't play an FPS with tens of milliseconds 
of network delay, so you need to locate servers close to the customers to 
keep latency low, plus you also don't want the access latency to eat up 
your latency budget so ADSL and cable goes out the window anyway, the only 
thing left is the sub-millisecond latency of ETTH.

Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in 
the network. State is expensive. What happened to KISS principle?

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 11 Nov 2010 20:44:36 -0000

> Sent: 11 November 2010 19:02
> To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
> S; Kathy McEwen; Mike Hammer (hmmr); GARCIA ARANDA, JOSE JAVIER (JOSE
> JAVIER)

Mikael - I think you already put your finger on the problem when you pointed
out that in your country ISPs are obliged to only promise customers what
they can reasonably deliver. In most of the world ISPs are still marketing
"Up to 8 Mbps" or "Up to 20Mbps" for services that at peak, for ~10% of
customers can manage ~6.5Mbps and 18Mbps respectively, with most customers
getting half that, and where the backhaul capacity is 10s of kbps per user
(contention ratios of ~100 to 1). 

What has gone wrong for ISP business models is that the world has changed,
with streaming and interactive services overtaking bulk transfer and web
browsing. ConEx may at times appear to be operator centric, but in many
places it is the customers that are suffering because ISPs are forced to use
pretty crude mechanisms to try and control the small percentage of heavy
users. Clearly everyone must benefit if background bulk data transfers move
to something like LEDBAT? But currently the operators treat that just the
same as any other P2P traffic so no-one benefits.

There is also the issue of fair allocation of upgrades. Obviously if an ISP
spends a lot of money on increasing their backhaul then this money has to
come from the customers. However as things stand the 20% of customers
grabbing 80% of the network will also grab 80% of this increased capacity,
so they are being even more heavily cross-subsidised. Clearly cross-subsidy
is always going to happen to an extent so long as you have flat fees for
access (even if you put in tiered fees, there is still cross-subsidy). But
this should not be excessive else customers suffer.

Toby

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 Nov 2010 21:57:39 +0100 (CET)

On Thu, 11 Nov 2010, Toby Moncaster wrote:

> What has gone wrong for ISP business models is that the world has 
> changed, with streaming and interactive services overtaking bulk 
> transfer and web browsing. ConEx may at times appear to be operator 
> centric, but in many places it is the customers that are suffering 
> because ISPs are forced to use pretty crude mechanisms to try and 
> control the small percentage of heavy users. Clearly everyone must 
> benefit if background bulk data transfers move to something like LEDBAT?

No, it's only the ISP that benefits. How do you move users to LEDBAT, 
what's the incentive for any user to move their traffic there? To give 
them an incentive, you must get off the flat fee model and start to cap 
monthly traffic that is not LEDBAT.

So if you're getting off the flat fee model, why not start charging users 
per usage or have a monthly cap with tokens to raise the cap or buy 
additional "credits"? It's non-discrimatory, and it's completely 
transparent as to what is going on. No secret in-the-black-box 
mistreatment or prioritization based on L4 information.

> There is also the issue of fair allocation of upgrades. Obviously if an 
> ISP spends a lot of money on increasing their backhaul then this money 
> has to come from the customers. However as things stand the 20% of 
> customers grabbing 80% of the network will also grab 80% of this 
> increased capacity, so they are being even more heavily 
> cross-subsidised. Clearly cross-subsidy is always going to happen to an 
> extent so long as you have flat fees for access (even if you put in 
> tiered fees, there is still cross-subsidy). But this should not be 
> excessive else customers suffer.

With global transit prices in the few dollars per megabit/month, the 
actual bandwidth cost per user even if they averaged 1 megabit/s/user at 
peak, is still not a major cost for the service which usually is in the 
several tens of dollars per month.

I don't buy any of the arguments I've seen in the discussion, they're not 
new, and they're not technical or economical, they're purely political and 
regulatory when you boil it down to the actual reasons for how things are 
what they are.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Nov 2010 04:55:15 +0100 (CET)

On Fri, 12 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

> Since several years ago, ARPU is frozen and even it has been reduced a 
> little. But traffic grows each year, and as you say, profit goes down. I 
> have check ARPU from Spanish operators and they are reduced

Yes, but the ARPU doesn't go down because traffic increases, it goes down 
due to competition and increased market penetration.

> Each year, a little, but the investments in network must increase to support the traffic growing.

Yes. That means profit is down.

> Priorization reduce queue times, with network full or not. For example, 
> IPTV services offered by operators uses priorization. But do not reduce 
> QoS to priorization. There are more operations involved in QoS.

Prioritization on the access line is good. Prioritization done because you 
want to flatline your distribution/core at peak times is bad.

> online gaming, in which latencies sometimes makes not possible to play 
> against users located in other countries, and in that case constraints 
> are not very restricted , however without QoS, they are impossible to 
> achieve today.

With hot potato routing, high latency to other countries depend on either 
bad network design or physical constraints when it comes to speed of light 
in fiber. QoS can't solve neither.

> Hard-core gamers have a high willingness to pay for virtualized games, 
> but today content providers can not offer virtualized games because 
> there is not QoS on demand in Internet.

Hard-core gamers won't accept 50ms of keypress/action delay.

> Have you read the draft? I promise you that Q-HTTP perhaps has an 
> horrible name, but it is KISS, for sure. It is application level, and 
> Q-HTTP alerts can be used for a lot of possibilities from adapting 
> mechanisms ( reduce bitrate or functionalities)  to priorization , 
> reservation, or whatever. It is not said what to do with the alerts in 
> the draft. It is only a powerful tool.

I started reading the draft but fell ill after reading it a while. It 
seems to do a lot of testing. We don't need more testing, we need 
performance information for existing traffic, not more test traffic.

And yes, Q-HTTP is HORRRIBLE name. And no, it's not KISS. Just the size 
of the draft and the number of sections says it's not KISS.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Nov 2010 10:40:51 +0100 (CET)

On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

> And testing is just a MUST. We need to know what is going wrong for THAT 
> flow, because not all the applications/flows have the same requirements.

No, testing is not a MUST. If you need to know what is going on with THAT 
flow, then you make sure you have insight into what THAT flow is 
experiencing, you don't inject more traffic.

Your time would be much better spent developing an API into the client IP 
stack to give insight into what TCP/RTP is actually experiencing 
(timestamping used to deduce jitter etc) than to create *more* traffic 
when facing adverse conditions.

And since you say "flow". I run *routers*. Routers act on a per-packet 
basis. They don't act on flows. They act on precedence/dscp values in each 
packet and queue according to policy if it exists, otherwise it does FIFO.

I hate testing. I'd much rather have insight into real traffic than 
creating test traffic. Test traffic can look fine where the real traffic 
is not. It's just amazing that we're sitting here some 30 years after TCP 
was invented and still have no tools for users to see what TCP is doing, 
short of dumping the packets on their interface and running wireshark on 
it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Nov 2010 10:43:04 +0100 (CET)

On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

> Then, why on earth ALL ISPs are using QoS in THEIR networks to guarantee 
> their own VoIP and Broadcast TV services to their customers???

All ISPs aren't doing this. I've worked for at least two who has VoIP 
services without it. Skype has no such requirement.

> QoS is ALWAYS a MUST for ISPs to ensure real-time services at any 
> moment. Q-HTTP is trying to open up that window to other third parties.

No, it's not a MUST. It's nice to have and increases network tolerance, 
but I've worked for ISPs that used overprovisioning and cheap equipment 
that just got the job done, and this was cheaper than buying the more 
expensive equipment that had a lot of intelligence in it.

Using QoS is ONE way of doing it, it's not the only one.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 12 Nov 2010 10:56:16 +0100 (CET)

On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

> [[Luismi]]: There is one only real thing we can trust in: ISP is there 
> because of PROFIT. If there is no profit there will be no investment at

Unfortunately there is no upper bound to the amount of profit to be made, 
so profit doesn't mean more network investment, it just means more profit. 
I thought that was obvious by now?

> helping ISPs to do MORE with the same money, and that will benefit 
> users.

If the network is full, it's full. Discriminating certain applications 
doesn't mean you're doing more, it's just that you're doing different 
things with the same bw. It's not more.

> With Q-HTTP we are also providing the tools to users to "audit" 
> what they are paying for. Users will pay extra money for superb services 
> (we are doing that right now when you pay a World of Warcraft or OnLive 
> subscription) and part of that money will end-up on the ISP. Sharing 
> profit between all the players is definetively a good thing IMHO.

Have you seen the roaming prices for mobile data? That's what you get when 
you abandon the bill-and-keep model.

> [[Luismi]]: The problem is that ISPs promises are just vague. Up to X 
> Mbps, with no delay/jitter guarantees is just fine for a lot of 
> applications. It is just not enough for real-time. Besides, a few 
> seconds congestion (for instance, a fiber goes down and all traffic 
> re-routes by another path that becomes 1.5 to 1 congested) will produce 
> a slow down in "standard" service and a complete melt-down in real-time. 
> THAT's what we want to protect. Real-Time application will obtain higher 
> priority during congestion (thus slowing down even more the standard 
> services) and EVERYTHING will be saved. Standard services will survive 
> with a period of "half-speed" and Real-Time will survive unaffected.

No, the real time service will be saved by sacrificing the other services. 
That's not EVERYTHING.

Also, I don't see why we need Q-HTTP to do this? This can be done today 
with existing features. The only upside I see with Q-HTTP is quality 
reporting, but it needs to be done in a different way.

> [[Luismi]]: Then there are a lot of services that never will fly out on 
> Internet. Take a look on OnLive service. They provide virtualized gaming 
> (play XBOX games on your TV without the console, just with a small 
> set-top-box that receives video and sends keys pressed on the pad) by 
> just bypassing the network and installing PoPs just half mile away from 
> your home. That is not economically optimized as you can imagine thus 
> they are translating that into a very expensive service. Just because 
> network does not provide what they need. With QoS, they can offer a 
> centralized service, with really cheaper deployment, lower the service 
> fee to users (win), making more profit (win) and paying a % of that to 
> ISP (win). If we like win-win, you must love this win-win-win (and even 
> better, ISP will re-invest part of that profit on network).

They can get QoS without Q-HTTP. They just need to make a deal with the 
ISP. Oh wait, they can't because of Net Neutrality restrictions.

Also, how do you plan to handle traffic in the outgoing direction from the 
consumer, normally CPEs don't have AQM, so if the customer is uploading 
photos at the same time as someone else in the household plays this game, 
you're bust anyway.

---

From: Kevin Mason <[email-masked]>
Date: Mon, 15 Nov 2010 17:24:19 +1300

I think much of this discussion is missing the root issue.

For any communication there is a source and sink. If the communication needs to pass information in both directions (other then underlying flow management) then each end becomes both a source and a sink. 

The path used for this communication is whatever is available. An ISP can influence where the source of anything a sink wish's to receive is, but commercial and regulatory models can impact beyond what an ISP can control.

As a very general rule, distance costs. There are exceptions but the longer the path generally the higher the cost. As an ISP on the opposite of the world to the majority of the English speaking populations this is more apparent to us that others!

To suggest that the global industry should or even could ensure that no congestion ever occurs between any source and any sink (i.e. the "core") is a little unrealistic. The probability of congestion on any path is never zero, regardless of how over provisioned it is. A forwarding link is always 100% utilised while it is forwarding a packet, so irrespective of the speed of the link and frequency of arrival of packets for onward transmission, if another packet arrives while the previous one is being sent then it has to wait. So how long does it have to wait before the link is considered "congested".

How long a packet might have to wait is determined by the ISP in its queue management and cpacity management at any forwarding point. However the ISP has no idea what the role of that packet is in the application the source and sink are exchanging data for, only the users do.

So the issue re congestion is not if congestion occurs, but how frequency, and how much delay (or loss) can each application tolerate before its value or utility to the source and sink diminishes. Telephony (and ATM) has a reservation mechanism built in, but there is still an "engineered" probability that congestion occurs and the reservation cannot be made.

So sources and sinks between them have options. 

One option discussed in this thread at length is that the application is, or could be, in some way elastic. But even this elasticity does not always come for free, the application has to build that in (clever codecs have royalties, as does processing power for user equipment to do any required computation at an acceptable rate), and the users may have to be willing to forgo some of the potential richness of their application when path bottlenecks occur. If this is acceptable, application elasticity can be effective in creating a more acceptable outcome more often for the total population of sources and sink combinations. 

Elasticity is not just a function of the application, albeit some applications tend to lend themselves to elastic behaviour more than others, but elasticity is more a function of what the source and sink are doing at the time, and is in part determined by what incentives service provider's put in place to encourage users to implement and/or enable elasticity in application behaviour. As has already been mentioned, the threshold when path conditions reach a point that begins to degrade the experience, regardless of application elasticity, is very low for some uses (e.g. FPS games).

The bandwidth for "acceptable" human speech conversation (telephony) is becoming trivial in relation to bandwidth required for other uses (e.g. HD video). So if any degree of fairness exists on paths, the probability that an acceptable path will exist for the duration of any source and sink speech path combination is getting higher by the day. So value for any differential mechanism for improving speech path performance probability (reservations, prioritisation) is rapidly diminishing except on paths where bandwidth remains expensive (e.g. wireless access) because of the scarcity of radio spectrum.

ISPs have a common problem, like any transport provider, in managing incentives (financial or market imposed) to discourage undue concentration of popular sources, and/or concentration of popular sinks, and to manage the balance between an individual's appetite to consume resources when it is most convenient to them (and therefore a high probability it is the most convenient time for the majority of other like users), verses modifying their behaviour (e.g. reducing consumption rate or shifting their consumption to periods of lower utilisation). Zero congestion can never be achieved. But the probability might remain very very low in most cases if providing excess capacity remains more efficient on the majority of paths rather than managing fair sharing of the resources. [art of the challenge is to give realistic expectation on what sources and sinks can reasonably expect using language they can understand.

So tools like LEDBAT, the proposed Q-HTTP, ECN, are all mechanisms to enable individuals (or their applications on their behalf) to identify when the path transfer function may be falling below a desired threshold for the preferred mode of application operation, and therefore enable users to change their behaviour if they are willing to (or to hope other users will change their behaviour first and leave space for them!). But there is little or no reward for this concession, so many will continue to just complain. These mechanisms do not inherently provide the provider with information that would enable the provider to intervene and referee who gets what if its considered to be getting too unfair. 

CONEX on the other hand is trying, as I understand it, to provide real time information to providers that would better enable providers to referee who get what if user (or upstream providers as the agent for upstream sources) on their own do not all play fairly, if providers choose to use the information in this way.

Cheers
Kevin Mason
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Toby Moncaster
> Sent: Friday, 12 November 2010 9:45 a.m.
> To: [email-masked]
> Cc: 'httpstreaming'; [email-masked]
> ISP

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Nov 2010 11:43:08 -0500

> Nice theory.  Until it gets down to who is going to pay for the

It is a mistake to call it over-provisioning. (Anything needed for proper performance I would call proper provisioning.) And, of course, the
customers pay for it. (It is interesting that no one ever seems to ask who pays for QOS.)

It is a question of where is it better to put resources, and I think that there is a long history to show that in many (not all) situations it is better to put resources in provisioning than in QOS. 

I also think that a modest amount of FEC would go a long way  to address concerns about real-time traffic, and I surprised that this is not
already used routinely. 

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Nov 2010 11:50:38 -0500

On Nov 12, 2010, at 4:12 AM, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

> 
> You said:
> 
> "Packet prioritization is only of value when the network is full. QoS is only of interest when BE works badly."
> 
> Then, why on earth ALL ISPs are using QoS in THEIR networks to guarantee their own VoIP and Broadcast TV services to their customers???
> 
> QoS is ALWAYS a MUST for ISPs to ensure real-time services at any moment. Q-HTTP is trying to open up that window to other third parties.
> 

I have three personal / office ISP accounts for Internet access. If any are offering QOS as a service, they sure haven't told me. (One, the
cable company, does do a "walled garden" type solution for IPTV, but I don't think that that is the type of QOS you are talking about.)  

Regards
Marshall

> And about "network state", there are different solutions to implement this, one includes network state, BUT IT IS NOT THE ONLY ONE. Indeed we tested one alternative in our lab with actual equipment....
> 
>    Saludos,
>         Luismi
> 
> De: Mikael Abrahamsson [mailto:[email-masked]] 
> Enviado el: jueves, 11 de noviembre de 2010 21:44
> CC: [email-masked]; httpstreaming; [email-masked]; Mike Hammer (hmmr); Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
> Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP
> 
> I don't get it. Are you saying that because there is more traffic, the user is paying less money per month? Yes, profit per customer might be down, but why should traffic volume decrease revenue?
> 
>> These ISP capabilities can be priced to developers/content providers, 
>> increasing ISP revenues. Capabilities such as location, presence, billing, security, QoS....
> 
> I agree that an ISP can be a micropayment provider and also provice some location information.
> 
>> One of the most important is QoS. If developers can not find 
>> profitable business Models, innovation is compromised. QoS means a mix 
>> of traffic engineering + priorization + etc
> 
> Packet prioritization is only of value when the network is full. QoS is only of interest when BE works badly.
> 
>> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to 
>> enable virtualization of games (like www.onlive.com, but using the 
>> network instead locating servers at last mille)
> 
> I don't get this either. You can't play an FPS with tens of milliseconds of network delay, so you need to locate servers close to the customers to keep latency low, plus you also don't want the access latency to eat up your latency budget so ADSL and cable goes out the window anyway, the only thing left is the sub-millisecond latency of ETTH.
> 
> Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in the network. State is expensive. What happened to KISS principle?
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Nov 2010 22:53:30 +0100 (CET)

On Tue, 16 Nov 2010, Ben Niven-Jenkins wrote:

> Your sentence above seems to ignore the backhaul? Which is strange as 
> the backhaul is a significant proportion of the overall cost and larger 
> than the cost of the core itself.

I don't know what you mean by backhaul, but I guess it's the 
"distribution" I'm talking about.

And it's my firm belief that "backhaul" should "never" be congested.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Nov 2010 22:56:06 +0100 (CET)

On Tue, 16 Nov 2010, Ben Niven-Jenkins wrote:

> Please cite evidence to support this assertion.

Are you for real? You're free to say what you want, but I have to "cite 
evidence"?

> At least for the ISPs I have worked with & for the margins are pretty 
> thin and while Transit/Peering costs are not the largest cost they are 
> not insignificant. We saw large scale "streaming events", e.g. day long 
> sports event broadcast on the Internet, had significant (localised) 
> impact to the Transit costs and if they were permanent (e.g. your 
> average 1 Mbps / user at peak time) they would have made a significant 
> impact to the bottom-line.

Well then, your experience differs from mine.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Nov 2010 22:58:08 +0100 (CET)

On Tue, 16 Nov 2010, Benjamin Niven-Jenkins wrote:

> Each "subscriber" gets a "fair" allocation of bandwidth but they (or 
> their ISP via their service bundle) choose how to prioritise packets 
> within their allocation.

The only "fair" allocation is the speed that was sold to the customer.

> Everyone's a winner :-)

The ISP is the winner because they get away with delivering less than what 
they promised the customer. The customers are being screwed, they're not 
winners.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Nov 2010 08:57:09 +0100 (CET)

On Wed, 17 Nov 2010, Benjamin Niven-Jenkins wrote:

> My point was that if you look at global transit prices they are 
> typically a few dollars a Mbps in the west. That pricing is not 
> universal across the globe.

That is true, but the reason for transit prices being high is usually a 
political problem, not a technical one.

No matter of talk about how nice QoS is hides the fact that if you're 
congesting anything else than the customer port, you're not giving the 
customer what he or she purchased. Also, the Internet became successful 
because it adhered to "keep it simple stupid" principle. The suggestions 
I've seen so far here is anything but simple and usually involves quite 
intrusive changes in equipment and business models.

I totally fail to see how making the network and payment models more 
complicated will make the network better. Money (capex and opex) should be 
spent on upgrading capacity and keeping the network simple, not trying to 
make the impact of too little capacity less noticable.

The network that has constrained access bandwidth (for instance mobile 
networks) already have advanced per-user queuing that assures "fair 
access" to the media. I would imagine cable networks have the same.

I see little reason to implement support for this in end-hosts, end-hosts 
should be greedy because that's how things work in real life. End-hosts 
are under the control of the end-user and thus can't be trusted to do "the 
right thing" when it comes to "fairness".

So anyone who wants to underprovision their network need to make sure they 
have 3GPP style bearer and scheduling concept working in their network to 
handle how resources are handled, we don't need new mechanisms for this, 
it's already been available for 10 years.

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 17 Nov 2010 17:00:16 +0000

> That is true, but the reason for transit prices being high is usually a political problem, not a technical one.

Just curious -- where is this conversation going? Are we to assume the same economic and political conditions throughout the world?

Personally, I am not convinced that the HTTP streaming "quality of experience" necessarily implies Internet QoS. But I thought we discuss IETF issues here, not UN issues (or OECD issues).

-- Rich

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Nov 2010 21:02:40 +0100 (CET)

On Wed, 17 Nov 2010, Woundy, Richard wrote:

> Personally, I am not convinced that the HTTP streaming "quality of 
> experience" necessarily implies Internet QoS. But I thought we discuss 
> IETF issues here, not UN issues (or OECD issues).

Some people describe core/distribution congestion as a force of nature 
that should be handled by a bunch of advanced technical means. I don't 
agree with this problem description, thus I guess it's hard to start to 
discuss a "solution" because I see "lack of capacity" should be solved by 
"install more capacity and make sure it can be done cheaply by means of 
making IP equipment low complexity" instead of "let's solve it by making 
the Internet more advanced and complicated so we can gracefully handle the 
advanced complicated network we now don't have the money to build out so 
it doesn't congest".

Since it's next to impossible to quantify the above factors and who is 
"right" (nobody is, it's a matter of opinion and world view), I guess 
that's why we're seeing the discussion going all over the place.

And I disagree that anything I have said indicates this to be a OECD or UN 
issue, it's a matter for the national regulators and politicians.

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 17 Nov 2010 14:22:29 -0600

In your view of how things work,
  if some congestion is not a part of expected behavior of the Internet core, 
    then what are the congestion control parts of TCP for?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mikael Abrahamsson
Sent: Wednesday, November 17, 2010 2:03 PM
To: [email-masked]
Cc: httpstreaming
Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 17 Nov 2010 16:52:21 -0500

On Nov 17, 2010, at 3:02 PM, Mikael Abrahamsson wrote:

> Some people describe core/distribution congestion as a force of nature that should be handled by a bunch of advanced technical means. I don't agree with this problem description, thus I guess it's hard to start to discuss a "solution" because I see "lack of capacity" should be solved by "install more capacity and make sure it can be done cheaply by means of making IP equipment low complexity" instead of "let's solve it by making the Internet more advanced and complicated so we can gracefully handle the advanced complicated network we now don't have the money to build out so it doesn't congest".

This is of course an "age-old" (well, 20-30 years) religious disagreement. Those that come out of the circuit switched telco world tend to think, QOS. Those that come out of the packet switched Internet world tend to think "provision properly." I don't expect to see such arguments cease in my lifetime. 

Regards (and all I will say on this topic on this list)
Marshall

> 
> Since it's next to impossible to quantify the above factors and who is "right" (nobody is, it's a matter of opinion and world view), I guess that's why we're seeing the discussion going all over the place.
> 
> And I disagree that anything I have said indicates this to be a OECD or UN issue, it's a matter for the national regulators and politicians.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Nov 2010 06:07:54 +0100 (CET)

>    then what are the congestion control parts of TCP for?

If you have a gig connected computer on a LAN connected to an ADSL line, 
of course there is going to be congestion, but it's on the access line, 
not in the core.

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 18 Nov 2010 09:33:32 -0000

> Sent: 18 November 2010 05:08
> To: STUART VENTERS
> Cc: [email-masked]
> >  if some congestion is not a part of expected behavior of the
> Internet
> > core,

Just to check, can you define what you mean by "access" and "core"? I get
the impression that there is a bit of confusion in some people's minds as to
where you place the backhaul (which many of us assume is the location of
most congestion).

A question for you - if we are going towards a world where the standard
domestic broadband connection runs at 100s of Mbps (e.g. FTTH), how fast do
you feel the core has to go to ensure your 0% congestion target? 

My understanding has always been that a key aim of congestion control is to
make efficient use of available capacity by finding the point at which it
just starts to congest before backing off sufficiently to let someone else
come in and share that capacity. I take it your view of the network assumes
this congestion signal still comes from the access so users are, in effect,
limited by the capacity constraints in their access.

To me (as an engineer by training, not a computer scientist), it would seem
inherently wrong to have a network that is not operating at a reasonable
percentage of capacity - in effect if you have to significantly
over-provision to remove congestion, you are wasting that capacity. 

BTW, I am all for keeping the real core simple - I think there is already a
lot of complexity that is unnecessary. Complexity should be pushed towards
the edges where possible... I am pretty confident that you can enable ConEx
without needing to add complexity to routers (unless you want routers that
are also intending to monitor the ConEx information).

Toby

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Nov 2010 12:31:23 +0100 (CET)

> where you place the backhaul (which many of us assume is the location of

"access" is the line/port that terminates in my apartment. It's where me 
as a customer is "alone" with just my own traffic. 
Core/distribution/aggregation is everything else.

> you feel the core has to go to ensure your 0% congestion target?

Probably multiples of 10G and 100G respectively. In ETTH deployment, you 
need gig between the active ethernet switches, you might need 2 bundled 
GigE or 10GE between them if you're running lots of multicast TV streams 
for Cable IPTV.

> I take it your view of the network assumes this congestion signal still 
> comes from the access so users are, in effect, limited by the capacity 
> constraints in their access.

Correct. They have purchased a capacity and they should have that capacity 
available to them at "all" times.

> over-provision to remove congestion, you are wasting that capacity.

No, the sweet spot is to reach 99% utilization of the core/aggregation 
network at peak. No unique customer can detect any core congestion, but 
you're running it close to full at peak.

This is provisioning "right". This also means that having 100 customers 
with 10meg per second on a docsis 2 network is most likely not going to 
work, because it's going to congest because you only need a few people 
using it at full speed at one time for the capacity to not be enough.

So the problem with the above isn't that some people are using an "unfair" 
amount of bw, it's that you're selling too much bw on a network technology 
that is not good enough for the job. Either you lower the customer bw or 
you upgrade the network. To congest it is the same thing as selling "300 
gram grilled strip loin" but delivering a hamburger because "you couldn't 
afford to procure the ingredients but you still wanted to be competitive 
in the market".

If you can't deliver 10 meg to the customer, don't sell 10 meg. It's that 
simple.

What the IETF should focus on is to create mechanisms where the end users 
can detect trickery from the ISPs and pressure them to actually deliver 
what they have sold, not to help the ISPs to hide this. I understand this 
is not "sexy", but it's the right thing to do.

---

From: STUART VENTERS <[email-masked]>
Date: Thu, 18 Nov 2010 08:09:58 -0600

Ok, so Mr. Gig and Mr. Adsl are communicating and TCP is only there to prevent congestion on the access ports.

So Mr. Gig and ADSL can do send any rate of packets their access will permit between each other and not affect anybody else in the Internet.

If this is all TCP is for, then why does it need the backoff mechanism?
   (Seems liek a simple acknowledge window like X.25 would have been sufficient.)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Nov 2010 15:31:52 +0100 (CET)

> If this is all TCP is for, then why does it need the backoff mechanism?

I see little reason to remove existing functionality. Do you?

---

From: STUART VENTERS <[email-masked]>
Date: Thu, 18 Nov 2010 09:26:42 -0600

Agreed, for the purpose here talking about removing backoff from TCP would be an unnecessary diversion.

I'm curious as to your thought on why backoff was put there in the first place?

Stuart,

Mikael

Mikael,

If this is all TCP is for, then why does it need the backoff mechanism?
   (Seems like a simple acknowledge window like X.25 would have been sufficient.)

Stuart

Stuart

Mikael

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Nov 2010 00:43:32 +0100 (CET)

> I'm curious as to your thought on why backoff was put there in the first 

Because it was and is needed, probably. What is your point?

---

From: STUART VENTERS <[email-masked]>
Date: Thu, 18 Nov 2010 19:36:27 -0600

I was thinking it might have been added to permit congestion collapse between unrelated traffic.
 As in traffic which comes from and goes to unrelated access ports.
  If this is so, then it would say that congestion in the core is nothing new.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Nov 2010 07:35:23 +0100 (CET)

>  If this is so, then it would say that congestion in the core is nothing new.

Of course this is nothing new, it's been around since the inception of 
packet networks that there are a lot of flows that compete, you get the 
same thing if you have multiple TCP flows from the same machine or if the 
customer has multiple machines in his home, and of course TCP should be 
able to handle this gracefully.

Again, I don't understand the relevance of this in this discussion.

---

From: STUART VENTERS <[email-masked]>
Date: Fri, 19 Nov 2010 06:43:09 -0600

Well if core congestion has been around since when TCP was created,
  why whould you expect Mr.Gig and Mr Adsl not to encounter some.

In other words I don't see the leap
  from the ISP sold me the BW so I want it
  to here's a plan for actually building a practical core to provide it.

I don't think I would like for the ISP to limit my access speed to what would give me a 95% congestion free packet path.
   (If they did they on average, I would run much slower with current economics.)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Nov 2010 06:31:56 +0100 (CET)

On Fri, 19 Nov 2010, STUART VENTERS wrote:

> Well if core congestion has been around since when TCP was created, why 
> whould you expect Mr.Gig and Mr Adsl not to encounter some.

The same way I expect to have food on my table. Just because 3-4 
generations back my family sometimes didn't have enough food doesn't mean 
I should expect that. And TCP needs to handle congestion because it needs 
it for access congestion, doesn't mean core congestion is a force of 
nature.

>  to here's a plan for actually building a practical core to provide it.

Where I live, there is no or little core congestion. There is no technical 
reason it can't be done, it's just economics and politics.

>   (If they did they on average, I would run much slower with current economics.)

The same way our ancestors worked hard for their kids to not go hungry, we 
should work hard to make sure our kids will get a good network to 
communicate on. We should work to provide tools for the end user to know 
more about their internet connection so they can demand the right things 
from the ISP, not give ISP tools to get out of providing what they sold.

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 20 Nov 2010 11:31:42 -0000

> Sent: 20 November 2010 05:32
> To: STUART VENTERS
> Cc: [email-masked]

Remember, you live in a very prosperous country, with a relatively small
population and with excellent links to the rest of the world. Most places in
the world are not so fortunate...

> 
> > I don't think I would like for the ISP to limit my access speed to
> what would give me a 95% congestion free packet path.

ConEx really isn't about ISPs grabbing more power. I agree that much of the
marketing done by ISPs is ridiculous, since it implies all customers can get
the maximum service rate at all times. However, that is not a matter for the
IETF to address. It is for regulators and competition to sort out. What the
IETF can do is provide tools that give ISPs better options for seeing where
there are problems. Current DPI/traffic pattern analysis coupled to fair use
policies is not a good solution for either party...

Realistically your idea of a completely congestion-free network is not going
to happen any time soon in most of the world (I accept Sweden seems to be an
exception). Therefore the IETF needs to try to improve the current
situation.

BTW, how do you see us avoiding congestion in undersea cables - for
instance, if Africa fully joins the Internet world, with a billion more
users connecting at broadband speeds. Do you envisage the capacity of the
expensive undersea cables being increased by several orders of magnitude to
cope with the extra traffic whilst guaranteeing no congestion? Or do you
have an alternative idea? 

Toby

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Nov 2010 12:39:26 +0100 (CET)

On Sat, 20 Nov 2010, Toby Moncaster wrote:

> users connecting at broadband speeds. Do you envisage the capacity of 
> the expensive undersea cables being increased by several orders of 
> magnitude to cope with the extra traffic whilst guaranteeing no 
> congestion? Or do you have an alternative idea?

It's already being expanded by magnitudes:

<http://manypossibilities.net/african-undersea-cables/>

5 terabits/s (just one system) means a billion people can get 5 megabits/s 
of capacity without congestion. (unless I made a 10^3 error in my 
calculations).

At an establishing costs of a few billion USDs per system that still is a 
few dollars per person for the whole continent, and that's the complete 
CAPEX for the investment, not a monthly cost.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 20 Nov 2010 16:30:19 +0100 (CET)

On Sat, 20 Nov 2010, Toby Moncaster wrote:

> population and with excellent links to the rest of the world. Most 
> places in the world are not so fortunate...

Yet, in the poorest countries I see the most expensive gear, because they 
have the least skill/experience and the most monopolies that rip off their 
customers. It's not a matter of prosperity really. And also, if it was a 
matter of prosperity, do they really need more advanced mechanisms or do 
they need simpler ways of producing more bandwidth? Imposing advanced 
"revenue sharing schemes", "QoS end-to-end" and so on, does that really 
help any poor contry get basic Internet, or does it help oligopoly ISPs 
get more money in their markets so they can give more profit?

As far as I can see so far, ConEx is dominated by oligopoly ISPs, 
academics and vendors who want to sell more advanced gear.

Why isn't there anyone who stands up for the regular user? Why isn't the 
KISS principle being used, why isn't there BCPs about how to solve this 
with the existing technology already available? ECN has after 8 years 
still not seen widespread adoption, yet there is talk about using even 
more flags in the headers.

I appreciate that people are doing this because they think they're doing 
the right thing, but I question if they really are.

In the markets where you get the most bandwidth for the least amount of 
money, ISPs generally can't afford a huge amount of CRS-1 or Juniper 
T-series, they instead build it using L3 switches that have little to no 
queue management, but they instead overprovision services so it works 
anyway.

> policies is not a good solution for either party...

I agree, but what the IETF is not doing, is providing tools to *users* to 
see where the problems are. Also, most of the documents I see here have 
problem description wording that consists of "unfair use" and similar 
terms. That is not helping the users, because there is no such thing as 
"unfair use" to me, I'm just trying to use what I've purchased.

> Realistically your idea of a completely congestion-free network is not 
> going to happen any time soon in most of the world (I accept Sweden 
> seems to be an exception). Therefore the IETF needs to try to improve 
> the current situation.

Yes it does, but not the onesided way being done right now.

---

From: ken carlberg <[email-masked]>
Date: Sat, 20 Nov 2010 12:14:05 -0500

On Nov 20, 2010, at 10:30 AM, Mikael Abrahamsson wrote:

> As far as I can see so far, ConEx is dominated by oligopoly ISPs, academics and vendors who want to sell more advanced gear.

I would recommend getting a better pair of glasses.

> Why isn't there anyone who stands up for the regular user? Why isn't the KISS principle being used, why isn't there BCPs about how to solve this with the existing technology already available? ECN has after 8 years still not seen widespread adoption, yet there is talk about using even more flags in the headers.

in complete and all seriousness, _please_ contribute and write these BCPs.  Or if you need some help, at least start with a draft, take it to one or more of the ADs (to see where it best fits in within the IETF) and ask for other contributors.  The next meeting is in Prague and I would certainly enjoy seeing you give a presentation on what you've written.  

> I agree, but what the IETF is not doing, is providing tools to *users* to see where the problems are. Also, most of the documents I see here have problem description wording that consists of "unfair use" and similar terms. That is not helping the users, because there is no such thing as "unfair use" to me, I'm just trying to use what I've purchased.

ok, so along the lines of "just trying to use what I've purchased", multicast then should be outlawed, banned, or at a minimum, should never be offered to clients of an ISP as a service because the network is replicating the traffic that the source did not pay for.  And before you come back and say "well, the receivers of paying for the service through their access link", that src/sink is not compensating the transits that build/maintain the trees traversing their network.  and so if by chance your ISP is offering multicast service, I hope the other users who never use it are not "unfairly" subsidizing the others that do.  

to take one step back, the market decides what gets adopted, the degree it gets adopted, and what does not get adopted.  Anybody recall IDPR, SDR?...didn't think so (and old timers are not allowed to respond :-).  And the stuff most of us are familiar with (RSVP, diff-serv, int-serv, MPLS, multicast) are also things that the market has made a statement on.  So if the market decides that that output of Conex isn't worth the trouble, then this will be reflected in its deployment.  Life goes on.

I have the feeling this thread has been beaten to death.  I did want to speak up this one time because I would like to see Mr Abrahamsson write up one of more drafts of the BCPs he's asking for.

cheers,

-ken

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 11 Nov 2010 10:14:42 -0600

Mikael,

<Start political view>
It is nice that you have a regulated monopoly of L1 in your market, but
that is not the case everywhere.  Who you are now is what you were when.
Some investors that paid to put copper or fiber into the ground would
prefer that the fruits of their labor not be stolen from them by
government fiat. 
<End of political view>

The telephone network had 100 years to get the blocking rates and
traffic engineering right.  Even now, in some countries you do still get
busy signal.  Should you then have the right to go out an cancel your
contract as a result?  I'll leave that to the market to decide.  And
yes, I support not having too lengthy a contract.  After all, we need to
vote with our feet every so often.

Also, comparing low-volume fairly predictable traffic flows like voice
to bursty flows like video is also problematic.

Mike

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 10:32 AM
To: Mike Hammer (hmmr)
Cc: David Singer; [email-masked]; Kathy McEwen; httpstreaming;
[email-masked]; Ingemar Johansson S; Mark Watson; GARCIA ARANDA,
JOSEJAVIER (JOSE JAVIER)
Subject: RE: [conex] [dispatch] [httpstreaming] Q-HTTP

In my market there are lots of players and they all have possibility to 
reach end users because there are "neutral" L1 providers to rent 
fiber/copper from. Competition works, and it stops aggregation
congestion.

> costs to overprovision the edge go up correspondingly.  The last mile
is 

The customer unique connection is ok to congest, it's running at the
speed 
the customer is paying for. It's everything up from that that should 
"never" be congested, because then you're not giving the customer what 
they're paying for. It's a breach of contract, pure and simple. You're 
free to statistically overbook your aggregation up to the point where
it's 
extremely rarely congesting.

Would you accept a telephony network that gave you no dialtone half of
the 
time you tried? I don't get it. Why would ISPs get away with not 
delivering what they have sold and why should we help them do this?

This works in all other markets, there false advertising is not
tolerated, 
why should it be in the ISP market? If you're buying 100 megabit/s of 
residential bw you should be able to use this speed at least 99% of the 
time, otherwise your ISP is overselling the resource and you're not 
getting what you have bought. If the ISP has gigabit aggregation it's
most 
likely that they can get away with 1000 users or more on this gige at
this 
speed, but they will not get away with it by doing 200 meg aggregation.

People talk about "fair". Fair business practice is to deliver what
you've 
sold. Fair is to treat every customers traffic equally, to deliver the 
packets they want delivered. That is the job of the ISP. It's not to 
mistreat some traffic or discriminate. If anything, THAT is the unfair 
part.

---

From: David Singer <[email-masked]>
Date: Thu, 11 Nov 2010 18:36:17 +0100

On Nov 11, 2010, at 18:15 , Mikael Abrahamsson wrote:
> 
> I don't want QoS guarantees, I want *all* my packets delivered, expediently, regardless if my neighbour is filling up his pipe or not. I have paid for it, and I want it DELIVERED. The postal office doesn't get to choose which of my letters it's ok to delay or throw away, they should just deliver them. Same with my ISP.
> 

It's interesting you say this in the context of real-time media, because I believe a network can give time guarantees ("any packet I deliver on this will be delivered within x ms") or delivery guarantees ("all packets will eventually be delivered") but it's hard (impossible, maybe) to do both.

eMail is an assured store-and-forward service.  IP packets are not.  Most users are unwilling to pay for guaranteed bandwidth availability to an ISP, who in turn would have to pay for guaranteed bandwidth upstream, and so on.  

Personally, I want my fair share of the shared 'roads' no matter how many others are sharing them, and I expect the 'last mile' personal link to have (at least) the capacity that was sold to me.

David Singer

---

From: "Kathy McEwen" <[email-masked]>
Date: Thu, 11 Nov 2010 11:55:14 -0600

Hello All,

  FYI... ATIS has issued a report on Policy Management, and have started a
Policy Management Focus Group with Assessment and Recommendations, including
numerous descriptions of market need.  Input was gathered from a large
number of contributing operators.  The report was issued in June of this
year, and includes the debates/arguments for managed QoS that also seem to
be bouncing around in this IETF BoF group.  Perhaps some of the ATIS study
work could be useful for the HTTP streaming justification as well...so as
not to duplicate work.  HTTP streaming is one piece of the bigger puzzle.
This IETF BoF group may want to liaison with this ATIS group.  

http://www.atis.org/documents/ATIS%20Policy%20Management%20Focus%20Group%20%
28PM-FG%29%20Final%20Report.pdf  

extracted:
1.1 Problem Statement

As network resources are increasingly stretched by unprecedented growth in
data traffic, Policy management is becoming an important industry topic.
Many service providers are concluding that it is unrealistic to continue
deploying additional capacity at the problem indefinitely. Policy management
is emerging as a potential tool to get more capacity out of installed
networks. Network policies are rules that are defined by the service
provider to control and charge for the resources used for communication
between end-points. Policies can also be used to bind the appropriate
bandwidth, and Quality of Service (QoS) to a given application or
subscriber. Policies can thus be used to control and better ensure the
user's experience in utilizing a service or application, wherever the
service is accessed. For example, a user streaming a video from a video
service can be guaranteed a high quality viewing experience whether they are
viewing the video on a smart phone or a High Definition TV.

Service convergence has been a vision of the communications industry for
years, and recent deployment has begun to translate this vision into
reality. Users can have a single contact number that will terminate on their
landline phone, mobile phone, or computer, depending upon their needs. A
given service can be accessed from a home network, a 3G network halfway
around the world, or from a WiFi hotspot at the coffee shop around the
corner. All of this demonstrates that service convergence is quickly
becoming a practical reality, but only at the basic connectivity level. In
most cases, once a user leaves their local service provider network they are
limited to best effort. In many cases today, that is good enough, and the
popularity of these services is growing exponentially. Growth at this level,
especially from smart phones and netbooks, is already beginning to strain
some networks, and it will only increase over time.

.../Kathy

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 11:16 AM
To: Mike Hammer (hmmr)
Cc: David Singer; [email-masked]; Kathy McEwen; httpstreaming;
[email-masked]; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, JOSEJAVIER
(JOSE JAVIER)
Subject: RE: [conex] [dispatch] [httpstreaming] Q-HTTP

On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote:

> I think the crux of our disagreement here is the difference between 
> what it takes to be an ISP and what it takes to be an access provider.  
> The economics are different.  Apples and oranges.  Saying it works for 

> However, comparing blocking (dial-tone means nothing, busy signal 
> does) of QoS guaranteed telephone links with non-QoS based congestion 
> is self-contradictory.  You are in essence saying that on the one hand 
> providers should not have the tools to provide QoS guarantees and on 
> the other hand slapping them for not being able to provide a QoS
guarantee.
> Now how fair is that?

I don't want QoS guarantees, I want *all* my packets delivered, expediently,
regardless if my neighbour is filling up his pipe or not. I have paid for
it, and I want it DELIVERED. The postal office doesn't get to choose which
of my letters it's ok to delay or throw away, they should just deliver them.
Same with my ISP.

> (Have you never tried to explain this to a non-techie and watched 
> their eyes glaze over?)

> don't impose that on everyone.

I am fine with packet prioritization within my access line. I have AQM on my
own access line, because it makes my access line perform better for my
packet mix (prioritizes my VoIP and ssh before my data heavy TCP sessions).

The problem I'm having here is that most talk is not about how to make the
customers access line behave better for the customer, it's to have certain
customers traffic be lower prioritized in the distribution and core, so ISPs
can oversubscribe more without customers being able to notice too much.

I resent that.

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 11 Nov 2010 12:03:53 -0600

David,

Yes, I have to agree that there are several approaches to how packets
are handled and they have to be balanced so you don't starve one or
another.

All packets can't be first in the queue, so some preferences and
ordering will take place.

There seems to be a gap between what a customer thinks they paid for and
what the provider thought they offered at that price.  The latter has to
make assumptions about traffic volume and mix and plan pricing and costs
to come out positive, or they won't be in business very long.  But, as
most traffic planners know, what you plan for and what traffic you get
can vary widely, especially with data.  If you want hard guarantees,
then you need to have private roads, but that is much more expensive and
most folks aren't willing to pay for it.

There are certain cases where without the QoS the service just doesn't
work.  For those, a user may be willing to pay to ensure the service.
If the network is engineered properly, then such services only take up a
fraction of the network.  If it is too large a share, does that mean the
QoS mechanism is bad?  No, it means the traffic engineering and
implementation is bad.  So, let us put the blame where it is due.  

The IETF should be about designing good tools.  Not attempting to
control bad usage of good tools.

My experience personally.  My package is 20Mb up and 20 Mb down.  What
do I normally get is 5Mb up and 10Mb down.  Am I upset?  No, because the
applications generally work.  There are tools out there to measure that.
If your provider is not even in the ball park of what he is offering,
then yeah, you need to switch.

Mike

-----Original Message-----
From: David Singer [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 12:36 PM
To: Mikael Abrahamsson
Cc: Mike Hammer (hmmr); [email-masked]; Kathy McEwen; httpstreaming;

expediently, regardless if my neighbour is filling up his pipe or not. I
have paid for it, and I want it DELIVERED. The postal office doesn't get
to choose which of my letters it's ok to delay or throw away, they
should just deliver them. Same with my ISP.

eMail is an assured store-and-forward service.  IP packets are not.
Most users are unwilling to pay for guaranteed bandwidth availability to
an ISP, who in turn would have to pay for guaranteed bandwidth upstream,
and so on.  

David Singer

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Thu, 11 Nov 2010 19:43:11 +0100

Hi,
   Just a different approach. Think in a traffic jam. I know it would be nice to live in a wonderful world with no jams, but they happen. Know compare you, going back home from work, and an ambulance with someone dying inside. Everybody gets away to let ambulance drive first. And that's OK.

   Now think on Internet. You are playing a Real-Time game and your neighbours are just downloading files. They can afford some amount of traffic loss (+delay/jitter) since TCP retransmisions will do the trick (just will take a little longer to get the job done) while you cannot afford losing (+delaying/jitterin) your traffic because if it happens, your opponent will blow you away from the arena. That's the point, all traffic flows are NOT the same and need different SLAs.

  Q-HTTP tries to address both problems:

- Enable subscriber to measure the SLA is being provided. This by itself is nice, since allows e2e players to solve the problem (reducing bit-rate of video if possible, for instance)
- Enables network operators to generate more revenue for "over-requirements". I dont think real-time was in mind whe Internet was created and we need to provide ISPs with new tools like this.

   I dont see any drawback in trying to anticipate to the future needs... 

    Saludos,
         Luismi

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Mikael Abrahamsson
Enviado el: jueves, 11 de noviembre de 2010 18:16
Para: Mike Hammer (hmmr)
CC: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S; Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

> oranges means it makes sense for apples is a non-sequitor.

For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs own L1 as well. What do you mean by it?

> the other hand slapping them for not being able to provide a QoS guarantee.
> Now how fair is that?

> (Have you never tried to explain this to a non-techie and watched 

That's why the IETF should work on tools to show this to people, not give ISPs tools to screw their customers.

> don't impose that on everyone.

I am fine with packet prioritization within my access line. I have AQM on my own access line, because it makes my access line perform better for my packet mix (prioritizes my VoIP and ssh before my data heavy TCP sessions).

The problem I'm having here is that most talk is not about how to make the customers access line behave better for the customer, it's to have certain customers traffic be lower prioritized in the distribution and core, so ISPs can oversubscribe more without customers being able to notice too much.

I resent that.

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Thu, 11 Nov 2010 20:51:45 +0100

Let's change one-way by two-ways ISP business

User---->content provider---> ISP <----flat fee user
 
Service providers are worried about ARPU. It is decreasing becasue
the "exaflood" phenomenon. The exponential traffic can not be sustained 
by the network, with incremental increases in bandwidth.

The answer consist on focuse on "ARPContent provider" instead on ARPU. And how?

The way to do that is by means of application enablement. If network provider 
exposes their capabilities to the developers/content providers , then 
internet applications becomes enough valuated to motivate users pay for them.

One of the most important is QoS. If developers can not find profitable business
Models, innovation is compromised. QoS means a mix of traffic engineering + priorization + etc

Look at gaming: this industry moves around 50 Billion euros per year, thereof 35
Billion are games and the rest (15%) hardware consoles. In the value chain of
Gaming industry, the distribution layer takes around 10%. (5 billion)

The potential of QoS for ISP only in Gaming are: distribution + hardware console savings + antipiracy + ...

Lets make the sum. 

virtual gaming is only one of the potential business of QoS

- Jose javier

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Fri, 12 Nov 2010 00:02:21 +0100

Mikael,

Since several years ago, ARPU is frozen and even it has been reduced a little. But traffic grows each year, and as you say, profit goes down. I have check ARPU from Spanish operators and they are reduced
Each year, a little, but the investments in network must increase to support the traffic growing.

An operator can do much more than micropayments and location. Can provide location, presence, availability status, geofencing functionalities, profiling, security based on attack patterns and virus signatures, child protection navigation, unified communications like integration voicemail to social networks, QoS (based on priorization, reservation, traffic mode at access nodes, traffic engineering, path computation) , storage, Content delivery network services, IPTV and IPTV based services, advertising, interactive advertising over IPTV, security, billing, wallet services for micropayments, remote call control, click to dial services, application store services, exposure of messaging services ( MMS, SMS), instant messaging services.....

Priorization reduce queue times, with network full or not. For example, IPTV services offered by operators uses priorization. But do not reduce QoS to priorization. There are more operations involved in QoS.

Regarding latency, it is possible reduce the latency using different operations over the network elements, such as changing traffic mode, choose a good path, priorization and so on. With around 50ms it is possible play a lot of virtualized games. Depending on the required latency, the application can work with a good user experience. But this is not only applicable to virtualized games, but also to traditional online gaming, in which latencies sometimes makes not possible to play against users located in other countries, and in that case constraints are not very restricted , however without QoS, they are impossible to achieve today. 

Hard-core gamers have a high willingness to pay for virtualized games, but today content providers can not offer virtualized games because there is not QoS on demand in Internet.

Have you read the draft? I promise you that Q-HTTP perhaps has an horrible name, but it is KISS, for sure. It is application level, and Q-HTTP alerts can be used for a lot of possibilities from  adapting mechanisms ( reduce bitrate or functionalities)  to priorization , reservation, or whatever. It is not said what to do with the alerts in the draft. It is only a powerful tool.

- Jose Javier

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Nov 2010 19:06:55 -0500

Hi,
one of the mailing lists you're CC'ing in this email thread is the DISPATCH WG list.  The purpose of the DISPATCH WG is to determine if and where to dispatch new work in RAI.  My guess is that even if there were agreement that there is a problem, and to solve the problem this way... this I-D would require a new WG, possibly not in RAI.  

Do the authors of this I-D plan to submit a proposed charter for a new WG into this Dispatch mailing list?

If not, I don't mean to be rude, but do you have to keep cc'ing the Dispatch mailing list? Don't you already have a mailing list dedicated for this discussion?  

And if you do plan to submit a charter, please email a proposed charter.

Don't take this as criticism, but Debating service provider OPEX, CAPEX, consumer market forces, and network design theory isn't really useful on the Dispatch mailing list.  We're just not the right group for that, methinks.  
Just my personal opinion.  To each his own.

-hadriel

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Fri, 12 Nov 2010 09:54:20 +0100

Few comments in-line.... 

    Saludos,
         Luismi

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Mikael Abrahamsson
Enviado el: jueves, 11 de noviembre de 2010 20:02
Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
CC: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S; Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

On Thu, 11 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

>   Just a different approach. Think in a traffic jam. I know it would 
> be nice to live in a wonderful world with no jams, but they happen. 
> Know compare you, going back home from work, and an ambulance with 
> someone dying inside. Everybody gets away to let ambulance drive 
> first. And that's OK.

When there is a traffic jam due to an accident it's ok. Where there is LA style traffic jams 12 hours of the day, that's not ok.

[[Luismi]]: I dont look why it is happening. It is just happening. And we need to do something about it in both cases (accident and 12-hour daily jam). 

> traffic loss (+delay/jitter) since TCP retransmisions will do the 
> trick (just will take a little longer to get the job done) while you 
> cannot afford losing (+delaying/jitterin) your traffic because if it 
> happens, your opponent will blow you away from the arena. That's the 
> point, all traffic flows are NOT the same and need different SLAs.

It would help the customer to get different treatment of his/her flows on the access. It would help the ISP and not the customer to do the same in the distribution/core. Who do we want to help? Is it the end user or is it the ISP? In the discussions in CONEX I mostly see people wanting to help the ISP, not the end user.

[[Luismi]]: There is one only real thing we can trust in: ISP is there because of PROFIT. If there is no profit there will be no investment at all and everything will just stale, that is precisely the reason while new real-time services are not flying on Internet as it should. We are helping ISPs to do MORE with the same money, and that will benefit users. With Q-HTTP we are also providing the tools to users to "audit" what they are paying for. Users will pay extra money for superb services (we are doing that right now when you pay a World of Warcraft or OnLive subscription) and part of that money will end-up on the ISP. Sharing profit between all the players is definetively a good thing IMHO.

> "over-requirements". I dont think real-time was in mind whe Internet 
> was created and we need to provide ISPs with new tools like this.

"over-requirement" as in "I want to actually get what you promised to deliver to me"?

[[Luismi]]: The problem is that ISPs promises are just vague. Up to X Mbps, with no delay/jitter guarantees is just fine for a lot of applications. It is just not enough for real-time. Besides, a few seconds congestion (for instance, a fiber goes down and all traffic re-routes by another path that becomes 1.5 to 1 congested) will produce a slow down in "standard" service and a complete melt-down in real-time. THAT's what we want to protect. Real-Time application will obtain higher priority during congestion (thus slowing down even more the standard services) and EVERYTHING will be saved. Standard services will survive with a period of "half-speed" and Real-Time will survive unaffected.

I don't buy it.

[[Luismi]]: Then there are a lot of services that never will fly out on Internet. Take a look on OnLive service. They provide virtualized gaming (play XBOX games on your TV without the console, just with a small set-top-box that receives video and sends keys pressed on the pad) by just bypassing the network and installing PoPs just half mile away from your home. That is not economically optimized as you can imagine thus they are translating that into a very expensive service. Just because network does not provide what they need. With QoS, they can offer a centralized service, with really cheaper deployment, lower the service fee to users (win), making more profit (win) and paying a % of that to ISP (win). If we like win-win, you must love this win-win-win (and even better, ISP will re-invest part of that profit on network).

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Fri, 12 Nov 2010 10:12:38 +0100

You said:

    Saludos,
         Luismi

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Fri, 12 Nov 2010 10:29:12 +0100

Q-HTTP is not only about testing. If you read that in detail, it has also the messages to alert when something is out of the line. And it also alerts (optionally) a third entity (besides user and SP) to react.

As we implemented this on the lab, we have an external policy manager that received this alert message, and by means of a policy change make the network in between to consider that specific flow or flows (as described in the alert message) to be treated in the same forwarding class as Broadcast TV. Everything keeps at best effort until congestion happens. Then, Q-HTTP alerts of SLA violation and this policy manager changes user profile. Real-Time flow (a virtualized game) keeps just playing with no problem (1 second of freeze) while other user (non-Q-HTTP) can't simply play, the game is just crazy (character is not moving or not stopping).

This was SIMPLE because it was based in the tools we already have in play in some ISPs (lab was based on a real-field network from a big ISP in Spain, with ADSL, aggregation, edge and core network). Simplicity is not measured by the number of pages ;). Of course, this is just a POSSIBLE implementation, not the only one.

And testing is just a MUST. We need to know what is going wrong for THAT flow, because not all the applications/flows have the same requirements.

And yes, i also think that Q-HTTP is not a good name :D

    Saludos,
         Luismi

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Mikael Abrahamsson
Enviado el: viernes, 12 de noviembre de 2010 4:55
Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
CC: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

On Fri, 12 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote:

> little. But traffic grows each year, and as you say, profit goes down. 
> I have check ARPU from Spanish operators and they are reduced

Yes, but the ARPU doesn't go down because traffic increases, it goes down due to competition and increased market penetration.

> Priorization reduce queue times, with network full or not. For 
> example, IPTV services offered by operators uses priorization. But do 
> not reduce QoS to priorization. There are more operations involved in QoS.

Prioritization on the access line is good. Prioritization done because you want to flatline your distribution/core at peak times is bad.

> are not very restricted , however without QoS, they are impossible to 

With hot potato routing, high latency to other countries depend on either bad network design or physical constraints when it comes to speed of light in fiber. QoS can't solve neither.

> the draft. It is only a powerful tool.

I started reading the draft but fell ill after reading it a while. It seems to do a lot of testing. We don't need more testing, we need performance information for existing traffic, not more test traffic.

And yes, Q-HTTP is HORRRIBLE name. And no, it's not KISS. Just the size of the draft and the number of sections says it's not KISS.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 12 Nov 2010 16:54:05 -0600

>    I dont see any drawback in trying to anticipate to the future needs...

Yes, but who is supposed pay for this anticipation?
And how do we know the anticipation is not wrong?

This falls into the risk area for business plans, but not for making
standards based on anticipation.

> I dont think real-time was in mind whe Internet was created
Wrong

>and we need to 
> provide ISPs with new tools like this.
Wrong again IMHO. ISPs would be better advised to fully utilize fiber.

Thanks, Henry

On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)"
<[email-masked]> wrote:

> Hi,
>    Just a different approach. Think in a traffic jam. I know it would be nice
> to live in a wonderful world with no jams, but they happen. Know compare you,
> going back home from work, and an ambulance with someone dying inside.
> Everybody gets away to let ambulance drive first. And that's OK.
> 
>    Now think on Internet. You are playing a Real-Time game and your neighbours
> are just downloading files. They can afford some amount of traffic loss
> (+delay/jitter) since TCP retransmisions will do the trick (just will take a
> little longer to get the job done) while you cannot afford losing
> (+delaying/jitterin) your traffic because if it happens, your opponent will
> blow you away from the arena. That's the point, all traffic flows are NOT the
> same and need different SLAs.
> 
> - Enable subscriber to measure the SLA is being provided. This by itself is
> nice, since allows e2e players to solve the problem (reducing bit-rate of
> video if possible, for instance)
> - Enables network operators to generate more revenue for "over-requirements".
> I dont think real-time was in mind whe Internet was created and we need to
> provide ISPs with new tools like this.
> 
> CC: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S;
> Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
> regardless if my neighbour is filling up his pipe or not. I have paid for it,
> and I want it DELIVERED. The postal office doesn't get to choose which of my
> letters it's ok to delay or throw away, they should just deliver them. Same
> with my ISP.
> 
> own access line, because it makes my access line perform better for my packet
> mix (prioritizes my VoIP and ssh before my data heavy TCP sessions).
>

---

From: Janet P Gunn <[email-masked]>
Date: Sat, 13 Nov 2010 09:48:04 -0500

> > same and need different SLAs.

I think your analogy is completely backwards.  Yes, everyone gets out of 
the way of the ambulance,
because the ambulance is more important.

But the real time game is NOT more important than downloading the file 
that contains the 
information on how to turn off the flow of the natural gas pipeline when 
there is an explosion.

What you are proposing in your analogy is not that "everyone should get 
out of the way of the ambulance", 
but that "everyone should get out of the brand new Ferrari so it can race 
with the Maserati." 

Janet

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Sat, 13 Nov 2010 17:26:26 +0100

hi Janet

i like your example about the explosion :-)

in my oppinion :

if the files about the way to avoid the explosion are so important,
then these files could be downloaded using SLA , and for sure the user or the
content provider will pay for that.

user-----(pay per FTP with quality)---->content provider-------(pay for quality)--------> ISP

user-----(pay per game with quality)---->content provider-------(pay for quality)--------> ISP

user----( no pay anything)----->content provider ------( no pay for quality)----->ISP

video or videogame is not more important than FTP, and FTP is not more important than video.
 It depends on how much the content provider or the user is willing to pay for it with QoS

in addition, Q-HTTP also may be used for detect packet loss and adjust FTP bitrate, or
change parallel FTP for sequential FTP. Q-HTTP is a tool. The decision to take when Q-HTTP alerts is open

i have attached an image named Q-HTTP_phases.jpg for quick understanding

- jose Javier

________________________________
De: Janet P Gunn [mailto:[email-masked]]
Enviado el: sábado, 13 de noviembre de 2010 15:48
Para: Henry Sinnreich
CC: [email-masked]; [email-masked]; [email-masked]; Mike Hammer (hmmr); httpstreaming; [email-masked]; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael Abrahamsson
Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP

> > same and need different SLAs.

I think your analogy is completely backwards.  Yes, everyone gets out of the way of the ambulance,
because the ambulance is more important.

But the real time game is NOT more important than downloading the file that contains the
information on how to turn off the flow of the natural gas pipeline when there is an explosion.

What you are proposing in your analogy is not that "everyone should get out of the way of the ambulance",
but that "everyone should get out of the brand new Ferrari so it can race with the Maserati."

Janet

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Mon, 15 Nov 2010 16:56:59 +0100

Hi,
   Good point, but anyway that file will also have that quality upgraded, and probably more than the online-game :).

   Today, 20% of people is just using 80% of the network, meaning that 80% of people is just using 20% of network. It doesn't seems fair to me that all the costs are paid equally. In a wonderful world, flat rates will just haf down and everything else will be "extras"....

    Saludos,
         Luismi

Janet

---

From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" <[email-masked]>
Date: Tue, 16 Nov 2010 11:31:07 +0100

hi Janet

i like your example about the explosion :-)
i have attached an image named Q-HTTP_phases.jpg for quick understanding  ( for people that have asked for it)

There are two ways to address an undesirable situation: "adaptative solutions" and "enhance QoS solutions"
For both cases Q-HTTP could be a handy tool

Regarding QoS solutions:
==================
If the files about the way to avoid the explosion are so important,
then these files could be downloaded using SLA , and for sure the user or the
content provider will pay for that.

Regarding adaptative solutions:
==================
 Q-HTTP also may be used for detect packet loss and adjust FTP bitrate, or
change parallel FTP for sequential FTP. Q-HTTP is a tool. The decision to take when Q-HTTP alerts is open

- jose Javier

Janet

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 16 Nov 2010 16:48:12 +0000

On 10 Nov 2010, at 22:08, Mikael Abrahamsson wrote:

>> 3) The people that build and operate the networks will double (quadruple?) their investments for no additional return out of the goodness of their hearts.
> 
> No, they're going to do it because if they don't give the customers what they promised, their customers are going to leave. This is if there is a functional market and customers actually have a choice of providers. I realise this is not the case in parts of the world, but that doesn't mean we should solve that by technical means, that's a political and regulatory problem, it doesn't have any technical solution.
> 
> Let's not forget that if you're congesting your core and distribution, you're not delivering what your customers have purchased. Period.
> 

It depends what the customer has purchased. Many times what the customer *thinks* they have purchased and what they have *actually* purchased are not the same.

> Congestion is acceptable on the customer access, it's not acceptable in the core. That means that any flows/pakets that should yield, are within a single customer domain, and thus in the customers own interest.

I used to work at a large PTT. Our design was to make the core non-blocking (i.e. does not drop packets except under multiple failures) and constrain the backhaul[1] (and to a lesser extent the access line itself).

Your sentence above seems to ignore the backhaul? Which is strange as the backhaul is a significant proportion of the overall cost and larger than the cost of the core itself.

Ben

[1] The bit that transports & aggregates many access connections into the core.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 16 Nov 2010 17:00:12 +0000

Mikael,

On 11 Nov 2010, at 20:57, Mikael Abrahamsson wrote:

>> There is also the issue of fair allocation of upgrades. Obviously if an ISP spends a lot of money on increasing their backhaul then this money has to come from the customers. However as things stand the 20% of customers grabbing 80% of the network will also grab 80% of this increased capacity, so they are being even more heavily cross-subsidised. Clearly cross-subsidy is always going to happen to an extent so long as you have flat fees for access (even if you put in tiered fees, there is still cross-subsidy). But this should not be excessive else customers suffer.
> 
> With global transit prices in the few dollars per megabit/month, the actual bandwidth cost per user even if they averaged 1 megabit/s/user at peak, is still not a major cost for the service which usually is in the several tens of dollars per month.

Please cite evidence to support this assertion. At least for the ISPs I have worked with & for the margins are pretty thin and while Transit/Peering costs are not the largest cost they are not insignificant. We saw large scale "streaming events", e.g. day long sports event broadcast on the Internet, had significant (localised) impact to the Transit costs and if they were permanent (e.g. your average 1 Mbps / user at peak time) they would have made a significant impact to the bottom-line.

Ben

---

From: David Singer <[email-masked]>
Date: Tue, 16 Nov 2010 10:03:21 -0800

On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote:

>   Now think on Internet. You are playing a Real-Time game and your neighbours are just downloading files. 

I am downloading a critical file that will enable me to respond to an urgent legal issue I have;  you are merely playing games.  You can wait.

I paid the same as you for my bandwidth, so I should get at least fair treatment, if not preferential -:)

David Singer

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 16 Nov 2010 12:09:52 -0600

Marshall,

It is over-provisioned if a large percentage of time, the majority of
capacity is sitting idle, versus time-shifting applications flows that
can be time shifted.

FEC does absolutely nothing to solve the latency and jitter issue.

Mike

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 11:43 AM
To: Mike Hammer (hmmr)
Cc: Mark Watson; Kathy McEwen; [email-masked]; httpstreaming;
[email-masked]; Ingemar Johansson S; GARCIA ARANDA, JOSEJAVIER (JOSE
JAVIER)
Subject: Re: [httpstreaming] [dispatch] Q-HTTP

> Nice theory.  Until it gets down to who is going to pay for the

It is a mistake to call it over-provisioning. (Anything needed for
proper performance I would call proper provisioning.) And, of course,
the
customers pay for it. (It is interesting that no one ever seems to ask
who pays for QOS.)

It is a question of where is it better to put resources, and I think
that there is a long history to show that in many (not all) situations
it is better to put resources in provisioning than in QOS. 

I also think that a modest amount of FEC would go a long way  to address
concerns about real-time traffic, and I surprised that this is not
already used routinely. 

Regards
Marshall 

if
much'
is

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 16 Nov 2010 12:46:53 -0600

David,

Let us be real.  If your file shows up 1 second later, does it matter?
Probably not.

If my voice or video packet shows up 1 second later, does it matter?
Yes, it gets dropped.

Mike

-----Original Message-----
From: David Singer [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 1:03 PM
To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
Cc: Mikael Abrahamsson; Mike Hammer (hmmr); [email-masked];
[email-masked]; httpstreaming; [email-masked]; Johansson S;
GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Subject: Re: [httpstreaming] [dispatch] [conex] Q-HTTP

On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)

>   Now think on Internet. You are playing a Real-Time game and your
neighbours are just downloading files. 

I am downloading a critical file that will enable me to respond to an
urgent legal issue I have;  you are merely playing games.  You can wait.

I paid the same as you for my bandwidth, so I should get at least fair
treatment, if not preferential -:)

David Singer

---

From: David Singer <[email-masked]>
Date: Tue, 16 Nov 2010 11:40:02 -0800

OK, so my example was slightly humorous.  But in general I think the claim that you can give preferential treatment -- preferential allocation of bandwidth -- to certain traffic simply because of its type is doubtful.  

Remember, this issue only comes up when there is a shortage;  and the thesis that I should be short-changed more (treated worse) than you because you are doing a real-time operation and I am not, is doubtful.

David Singer

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Nov 2010 13:53:12 -0600

> OK, so my example was slightly humorous.  But in general I think the claim that you can give preferential treatment -- preferential allocation of bandwidth -- to certain traffic simply because of i…

I think you need to differentiate between "preferential" and "appropriate."

For example, your gaming neighbor probably would dislike a policy of 
"deliver this packet with little regard to latency, but with a higher 
effort" approach. And you, in downloading a file, probably would dislike 
a policy of "deliver this packet with very little latency, unless it 
can't get there in time, in which case you should just drop it."

/a

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Tue, 16 Nov 2010 20:47:06 +0000

David,

> Remember, this issue only comes up when there is a shortage;  and the thesis that I should be short-changed more (treated worse) than you because you are doing a real-time operation and I am not, i…

One solution that I have deployed in a previous life & that I know is used by other ISPs is hierarchical shaping at the BNG.

Each "subscriber" gets a "fair" allocation of bandwidth but they (or their ISP via their service bundle) choose how to prioritise packets within their allocation.

You can then prioritise your download over your daughter's VoIP and Mike can prioritise his VoIP over his daughter's download while you both get the bandwidth you have individually "paid" for.

Everyone's a winner :-)

Ben

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Wed, 17 Nov 2010 07:26:40 +0000

On 16 Nov 2010, at 21:56, Mikael Abrahamsson wrote:

> Are you for real? You're free to say what you want, but I have to "cite evidence"?
> 

My language probably came across a little harshly. My point was that if you look at global transit prices they are typically a few dollars a Mbps in the west. That pricing is not universal across the globe.
 
>> At least for the ISPs I have worked with & for the margins are pretty thin and while Transit/Peering costs are not the largest cost they are not insignificant. We saw large scale "streaming events", e.g. day long sports event broadcast on the Internet, had significant (localised) impact to the Transit costs and if they were permanent (e.g. your average 1 Mbps / user at peak time) they would have made a significant impact to the bottom-line.
> 

Indeed.

Ben

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Wed, 17 Nov 2010 11:08:29 +0100

I have worked extensively (in engineering and network design) for every ISP on Spain (Telefonica, France Telecom, Orange, BT...) and all of them have QoS in their network. They use it to provide VoIP, Broadcast TV and to protect Bussiness Services (VPLS and IP-VPN). Indeed the only traffic that is Best-Effort is internet traffic for residential users (internet for corporate customers has also higher priority).

Maybe they are not SELLING QoS directly to their customers. But for sure they are USING it a lot. What we propose is opening that feature to everyone, providing a tool to monitor and control QoS to everyone.

    Saludos,
         Luismi

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Marshall Eubanks
Enviado el: martes, 16 de noviembre de 2010 17:51
Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
CC: [email-masked]; httpstreaming; [email-masked]; Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Mikael Abrahamsson
Asunto: Re: [dispatch] [httpstreaming] [conex] Q-HTTP

> QoS is ALWAYS a MUST for ISPs to ensure real-time services at any moment. Q-HTTP is trying to open up that window to other third parties.

I have three personal / office ISP accounts for Internet access. If any are offering QOS as a service, they sure haven't told me. (One, the cable company, does do a "walled garden" type solution for IPTV, but I don't think that that is the type of QOS you are talking about.)  

Regards
Marshall

> De: Mikael Abrahamsson [mailto:[email-masked]] Enviado el: jueves, 
> 11 de noviembre de 2010 21:44
> CC: [email-masked]; httpstreaming; [email-masked]; Mike Hammer 
> (hmmr); Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL 
> (LUIS MIGUEL)
>> the "exaflood" phenomenon. The exponential traffic can not be 
>> sustained by the network, with incremental increases in bandwidth.
> 
>> profitable business Models, innovation is compromised. QoS means a 
>> mix of traffic engineering + priorization + etc
> 
>> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) 
>> to enable virtualization of games (like www.onlive.com, but using the

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Wed, 17 Nov 2010 11:17:50 +0100

Importance is something heavely subjective. If your file is so critical you will pay for QoS the same as i am paying for gaming, to ensure that flow (file download) is delivered as expected. Moreover, our proposal includes the different requirements for every flow, gaming and critical file downloading will have different needs and network can do different things to ensure both services are honouring its SLA.

You paid the same for bandwidth, but if i pay an "extra" to ensure my gaming experience we are not fair anymore....

Everyone thinks that people in your flight using bussiness class has the right to board first (among other privileges) because the pay more, but on the other hand, Internet should remain "fair"...I dont really see any difference, you obtain what you pay for, if you pay more you will have more (for sure not in an 1:1 way).

INDEED, dont forget that i am personally convinced that this Q-HTTP initiative should help ISPs to lower flat rates. If you only need Internet access for emailing and web surfing you will pay LESS, and people that make extensive use of resources will pay More. That is fairness for me :D.

    Saludos,
         Luismi

-----Mensaje original-----
De: David Singer [mailto:[email-masked]] 
Enviado el: martes, 16 de noviembre de 2010 19:03
Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
CC: Mikael Abrahamsson; Mike Hammer (hmmr); [email-masked]; [email-masked]; httpstreaming; [email-masked]; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: Re: [httpstreaming] [dispatch] [conex] Q-HTTP

David Singer

---

From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" <[email-masked]>
Date: Wed, 17 Nov 2010 11:20:37 +0100

You are treated worse because you are paying less :D. I think it is a good assumption to think that if you are not willing to pay an extra cost, maybe what you are doing is not so important...

When i am in a hurry i take the toll highway, while when i am not i use the toll-free (ussually jammed) one....

    Saludos,
         Luismi

-----Mensaje original-----
De: David Singer [mailto:[email-masked]] 
Enviado el: martes, 16 de noviembre de 2010 20:40
Para: Mike Hammer
CC: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael Abrahamsson; [email-masked]; [email-masked]; httpstreaming; [email-masked]; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)
Asunto: Re: [httpstreaming] [dispatch] [conex] Q-HTTP

David Singer

---

From: Kevin Mason <[email-masked]>
Date: Mon, 22 Nov 2010 13:46:19 +1300

Cheers
Kevin Mason
> Sent: Sunday, 21 November 2010 4:30 a.m.
> To: Toby Moncaster
> Cc: [email-masked]

[Kevin Mason] Mikael you seem to think that paths to every destination that any user may wish to reach at any time should be dimensioned in such a way that capacity matching or exceeding the user's access speed will always be available.

Your comparison re Africa might be valid if the only path everybody in Africa used was the same. However even if all of Africa was served by a single cable, say to Western Europe, unless all Africans only used a single source in Western Europe, then the capacity required on every possible route beyond the European end of the cable in western Europe would result in a very large investment that all African users would have to alos contribute to, as they are the ones using it. 

On the assumption that nobody, regardless of local politics and commercialism, can afford a dedicated access speed path to every possible destination, then providers must make choices about how much capacity to provision on what core paths. This is typically based on average typical peak behaviour. But by definition events do occur, more frequently that most see or wish to admit, that result in non typical average flows, so congestion cannot be avoided if instantaneous source and sink combinations occurs that are other than average.

On average many providers try to ensure that congestion (whatever the definition of "congestion" might be) does not occur MOST of the time as far as any measurement systems they are currently using can detect. However end user applications can often detect it now, typically in variation in RTT and/or some loss. But just because providers can't see it today does not mean it is never occurring, or if they could see it that to always avoid any congestion ever would be commercially viable for every combination of source and sink paths users collectively chose to use at any instant in time.
> more flags in the headers. 

So I would suggest that providers believe, that users believe, TCP congestion mechanisms are good enough, and user don't know what might be different if ECN was turned on by providers and users enabled it on their equipment. So is ECN unnecessary or is there just a market education problem?

So if providers had better mechanisms to observe congestion occurring, that is in many cases is being masked by long term aggregate averaging measurements today AND provider systems could identify what paths (source and sink combinations) were being affected by it 9and not just the next hop), then there might be benefits for both providers and their users. It remains that the potential for mis use of information always exists, but this is not a IETF issue, it's a market structure one in each jurisdiction. My expectation is enough providers will use the information to reward those that assist in making the overall service more affordable for all, just as electricity companies use off-peak metered rates to reward users for allowing them to turn off some of their load when demand peaks occur.
> queue management, but they instead overprovision services so it works

You appear to assume that devices, router/switches are the most significant cost component. This may be the case for very high density geographies, but not for all. The cost of carrying internet traffic from the south pacific to/from Europe Asia and the US is not dominated by routing/swtiching equipment!.
> "unfair use" to me, I'm just trying to use what I've purchased.[Kevin Mason] 

[Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are primarily tools for users so I don't see any lack of "tools" for users. CONEX I understand is trying to provide some of that visibility to providers because zero congestion is not achievable at any realistic price unless all sources directly connected to access lines (i.e. there is no core !).

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 21 Nov 2010 23:14:21 -0500

I have pinged the Secretariat to stop all of these 4-day old messages. 

Regards
Marshall

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Nov 2010 07:18:38 +0100 (CET)

On Mon, 22 Nov 2010, Kevin Mason wrote:

> [Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are 
> primarily tools for users so I don't see any lack of "tools" for users. 
> CONEX I understand is trying to provide some of that visibility to 
> providers because zero congestion is not achievable at any realistic 
> price unless all sources directly connected to access lines (i.e. there 
> is no core !).

At IETF75 I proposed in multiple WGs (and at the general session one 
evening) to have some work done to give the user insight into what TCP 
(and other protocols) is doing. I still haven't seen any takers or even 
someone saying this is a way forward that they think is worthwile spending 
time on. Zero.

So I would like to say that using TCP as an example of "tool" for a user 
to see what is going "on", is not something I agree on today. Q-HTTP might 
do it if I understand it correctly, but I don't like that it actually 
introduces testing traffic, when instead my strong opinion is that one 
should not introduce testing traffic, one should instead look at the real 
traffic and what is going on there. TCP has lots of tools to help itself 
(timestamping, noticing single packet loss etc), but there is no way to 
expose this to the general user. I can fire up wireshark and spend 
minutes/hours trying to figure out what is going on, but I've been doing 
packet networking for 15+ years and know my way around that tool.

I don't know what tools LEDBAT has to inform the user, but I guess since 
it's "background" the user can see the transfer speed to see what extra 
bandwidth is available, and when it's very low, the network is obviously 
full.

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 22 Nov 2010 14:50:08 -0000

> Sent: 22 November 2010 06:19
> To: Kevin Mason
> Cc: [email-masked]

Or perhaps they think that is a job for OS writers, not the IETF? There are
limits to what the IETF should take on else we will spread ourselves rather
too thin...

> bandwidth is available, and when it's very low, the network is

To my mind it is NOT sensible to show users what is happening. Bluntly, 99%
of people couldn't care less how the Internet works, what their PC is doing
when they start a Skype video call, etc, any more than they want to know
what their car's engine management system does when they press the gas
pedal.

What things like LEDBAT are trying to do is translate the user's behaviour
(we want a file, so we tell our PC to find it and download it) into sensible
actions (user is also doing something interactive and if the file transfer
grabs all their bandwidth suddenly their interactive session dies, so we
slow the transfer down until the interactive session goes away).

I do believe there is room for improvement (perhaps an app that allows the
user to say, actually this transfer is quite important as I want to watch
this film tonight (said film being copyright free or paid for of course ;)

I am not convinced the IETF should be going into that much detail though...

Toby

---

From: Kevin Mason <[email-masked]>
Date: Tue, 23 Nov 2010 12:41:19 +1300

Cheers
Kevin Mason
> From: Toby Moncaster [mailto:[email-masked]]
> Sent: Tuesday, 23 November 2010 3:50 a.m.
> To: 'Mikael Abrahamsson'; Kevin Mason
> Cc: [email-masked]
[Kevin Mason] My definition of "tool" is perhaps wider that yours, in that these protocols already expose end to end path information to end user devices. The user's application is acting on the user's behalf, so the extent to which path information derived from the transport protocol is literally conveyed to the "human user", rather than acted on by the application in an attempt to achieve the experience or outcome preferences set by the human user, are from a network behaviour perspective synonymous.

No equivalent information is currently exposed to the network to enable a service provider to observe the current impact of user behaviour to craft and manage suitable incentives and rewards for mutually beneficial behaviours.