Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt]

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Aug 2001 18:42:03 -0500

> Subject: Re: draft-conta-ipv6-flow-label-02.txt
> Date: Fri, 10 Aug 2001 18:33:54 +0900
> From: Jun-ichiro itojun Hagino <[email-masked]>
> To: [email-masked]
> 
> >       with many of the diffserv-oriented encoding, there are possibilities
> >       for routers to get tricked by originating nodes, leading to theft of
> >       traffic and/or simple kernel panic (if we put header length into flow
> >       label field, and if your router is careless - if you are careful you
> >       are not speeding things up and there's no meaning in embedding
> >       header length into flow label field).
> 
>         also, if you are going to rewrite the field for the sake of diffserv,
>         why don't you use traffic class field (6bit)?

I didn't see this until today because some daemon threw me off the mailing list...

The traffic class field is not enough. If you have to re-classify traffic at
an administrative boundary, then by definition at that point the traffic class
field is inadequate; you need more information. The advantage that IPv6 has 
is that even when the header is partly hidden by IPSEC, the flow label is
available to carry additional semantics. The actual proposal is to use the
PHB identifier which has end to end semantics.

   Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Blake <[email-masked]>
Date: Tue, 14 Aug 2001 20:06:22 -0400

> PHB identifier which has end to end semantics.

Brian,

The counter argument against putting port information in the flow label
is that it gives the application the incentive to lie (by putting bogus
information in the flow label), without the impact of breaking the receiver's
port demultiplexing.

The counter argument against putting the PHB id in the flow label is that
it is irrelevant: the way PHBs have been defined has virtually no
relationship to any application QoS performance parameters, and furthermore,
the downstream network usually couldn't care less what the application
desires.

If I am reclassifying traffic at an administrative boundary then by 
definition I don't care about or trust the "QoS information" in the
packet as anything more than a hint which I am free to ignore (depending
on the TCS I have with the upstream network).  When crossing security
boundaries the only field which I am reasonably safe to trust is the
destination address.  Protocol/port filtering only makes sense within
an enterprise network or at the access provider's edge.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                  (919)472-9913

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 15:20:38 +0900

>PHB identifier which has end to end semantics.

	I heard the presentation differently.  in IETF51 presentation Alex
	Conta made the following proposals, at least:
	- putting PHB value
		not trustworthy.
	- putting total extension header length
		if the originator lies about the value, intermediate routers
		can go panic.
	- putting port/addr/whatever encoded
		if the originator lies about the value, theft-of-service
		happens.
	none of these values are trustworthy, since originator can lie about
	those.  because these values are not trustworthy, intermediate routers
	need to get those values by normal ways (by chasing extension header
	chain, or whatevr), and therefore, flow label value is just wasted.

	I particularly don't like the idea of putting total extension header
	length.  as soon as it gets deployed bad guys can mount various attacks.

	So, back to my original posting, I vote for end-to-end pseudorandom
	20bit value.  intermediate router MAY use it to hash the traffic,
	that's all.

itojun

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 15 Aug 2001 03:39:59 -0400

> destination address.  

yes, exactly.  there's no point in putting cleartext port numbers in
headers; moreover, even if they were somehow required to transit the
network, there would be a strong incentive for cooperating IPsec
implementations to include deliberately incorrect port numbers to
reduce the amount of information available for traffic analysis.

So, I'm afraid that in the long run any "cleartext port numbers" field
would have to be treated at administrative boundaries with the same
level of suspicion as the diffserv code point..

> Protocol/port filtering only makes sense within an enterprise
> network or at the access provider's edge.

And it only makes sense at the access provider's edge if the customer
is silly enough to send traffic in the clear..

						- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2001 08:35:12 -0500

I didn't hear the presentation since I was sick. But yes, the draft
analyses all those ideas and rejects them - the surviving proposal
is to use the PHB ID. I will comment on that in response to Steve's
message.

The pseudorandom case works for intserv and is irrelevant to diffserv.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2001 08:43:04 -0500

> information in the flow label), without the impact of breaking the receiver's

Quite agree. This option doesn't work. Sorry if the draft doesn't make it
clear that we reject it.

> the downstream network usually couldn't care less what the application

This is debatable. Since there is a potentially large number of IANA-registered
PHB IDs, they can actually be given more semantics than a true PHB. It's
certainly stretching the concept. It's also the only way I can see to make the
flow label relevant to diffserv; but we are at liberty to conclude that it
can't be done and we leave the flow label exactly as it is, relevant only
to intserv.

> an enterprise network or at the access provider's edge.

Well yes, but when the packet has an ESP header you are in trouble. The idea
of adding some semantics in the flow label is to deal with the ESP case.
If you aren't prepared to believe that field then of course all is lost
and you can only do address based classification.

Regards
    Brian

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 21:36:14 +0700

Date:        Wed, 15 Aug 2001 08:43:04 -0500
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

This is way outside my area, but ...

  | Well yes, but when the packet has an ESP header you are in trouble. The idea
  | of adding some semantics in the flow label is to deal with the ESP case.
  | If you aren't prepared to believe that field then of course all is lost
  | and you can only do address based classification.

I think the point was that if you believe the data, then you can be guaranteed
that people will cheat.

Therefore you cannot believe the field.

Therefore all you are left with is the address.

(which is pretty much as you just said, but you left off the final step)

Therefore it is pointless adding any semantics to the field, because
even if there, they can't (won't) be used.

kre

---

From: Alex Conta <[email-masked]>
Date: Wed, 15 Aug 2001 10:30:18 -0400

Steve,

> information in the flow label), without the impact of breaking the receiver's

Independent of what Brian may have to say....

What you say gives the impression that the draft introduces a higher
security risk, but that is 
absolutely not true. 

The QoS processing is affected the same way, whether there is a port
number or something else in the flow label. That is to say that the
security impact of using a port number, or any other label format, is
not different than with the RFC 2460 definition of the flow label
format, if a user can
change as pleases packet headers before packets are sent.

> relationship to any application QoS performance parameters,

The relationship or non-relationship with an application prior to using
the PHB value in the flow label is irrelevant. One could use anything as
a value, including a predefined IANA value. Using the PHB ID is clever,
because it avoids the hassles of another set of IANA numbers.

>  and furthermore,

It is correct to say "usually", because it is not "always". There are
plenty of situations, where there is a merit for the downstream
providers. Nevertheless, it was stated quite clearly in the draft, the
best and direct application is in access networks.

> on the TCS I have with the upstream network). 

You are free to ignore, but you should also be free to consider,
depending on SLS/TCS. The point is in giving the users/providers the
choice.

> [...]

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2001 10:49:29 -0500

> even if there, they can't (won't) be used.

But there's a recursion here. If you choose to believe port and protocol
numbers, then all cheaters have to do is encapsulate their low priority
packets in what look like VoIP packets and they will get real time
performance. So whatever you choose to believe (except the destination
address) could be bogus.

It turns out this doesn't matter. If somebody cheats in this way, they will
pay the tariff for better QoS anyway - so why would the ISP care? I think
that is the rebuttal to Steve Blake's argument - customers pay for the service they
actually get, even if they are disguising their traffic. So sure they can cheat,
but they are the losers.

   Brian

---

From: Alex Conta <[email-masked]>
Date: Wed, 15 Aug 2001 12:21:35 -0400

Itojun,

You seem to ignore that both RFC 1883, and RFC 2460 themselves state
that the flow label definition has limitations. Since 1994-95, and 97-98
when those documents were written/reviewed, a lot more progress has been
made relative to QOS and labeling traffic, in terms of architecture,
specifications, and applicability. 

You state that the current definition is perfect, or it suits you
perfect. But you do
not want to accept a win-win situation, which is a mechanism that 
 - does not eliminate what suits you, but also
 - would suit others.

I am going to try to keep religion out, and respond to the technical
content of what you're saying whatever that may be - please see bellow.

Alex

>         Conta made the following proposals, at least:

The PHB is as trustworthy as anything else, including the pseudo-random
value. If a user can set values as pleases, it can do that with the
pseudo-random number as well.

>                 if the originator lies about the value, intermediate routers

I disagree. 

"less than the size of the packet" is a simple, cheap, straight forward
validation test of the headers length, that would ensure that nothing
wrong can happen, regardless of memory being partioned and protected.

Even without the validation, the reduced number of bits available for
the length is forcing a reasonable limit on the length. The TCP/UDP
ports are accessed for "read", and the values are not used as pointers
or offsets. Assuming an implementation that enforces memory
partitioning, the "kernel" has most likely "read" access anywhere in
memory, so "memory access violation" is unlikely.

Also please note that the use of a total header length would not be
conceptually, and practically
different than IPv4. The IHL field in the IPv4 header includes the
length of the main header fields, and the IPv4 options. Some of the IPv4
options are of a variable length. A variable size IPv4 option
carries a field indicating the length. We knew how to implement this
back many years ago, right?, so we should be able to implement this
carefully for IPv6, if need be.

>                 if the originator lies about the value, theft-of-service

As said above, the security risk is not higher than with the
pseudo-random number.

---

From: Steve Blake <[email-masked]>
Date: Wed, 15 Aug 2001 12:46:28 -0400

> actually get, even if they are disguising their traffic. So sure they can cheat,

To summarize: the customer will pay for higher CoS, and can either explicitly
"signal" the provider of the desired per-packet CoS (via the traffic class
or flow label fields), or let the provider infer the required per-packet CoS,
according to agreement, by looking at the protocol/ports and addresses.

Pushing protocol/port filtering to the provider is easier to deploy if I
trust the hosts in my network: I don't have to change the hosts or deploy
any Diffserv filtering/marking in my firewall.  If I trust the hosts to
put legitimate values in the flow label field, then I can just as easilly
trust them to put legitimate values in the traffic class field.  If I 
don't trust my hosts, then I need to enforce my Diffserv policy at the
firewall anyway.

So I think the argument boils down to whether 6 bits or 20 bits is enough
to convey application CoS preferences to the network.

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2001 11:57:44 -0500

See comment at the end.

> to convey application CoS preferences to the network.

Excellent summary. We originally chose a 6 bit diffserv field partly because
it was available in both IPv4 and IPv6, and partly because it allows for
very efficient classification in *core* routers, with the more demanding
multi-field classification being left to border routers. 

The question before the house (in the end that means both ipng and diffserv)
is whether the added complexity of adding the flow label to the diffserv
model is justified by the gain in expressiveness. It doesn't do anything
for the trust model.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Aug 2001 10:11:35 -0700 (PDT)

> model is justified by the gain in expressiveness. It doesn't do anything

   I haven't heard about any imminent shortage of DSCP's.
   Indeed, it seems that there's only a small handful
   (2-6) that I've ever heard people contemplating. Maybe
   I just don't travel in the right circles...

	  Mike

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 16 Aug 2001 14:18:11 +0900

>pseudo-random number as well.

	but if you look at the number as PHB, you are trusting that the
	originating system have put a meaningful, and correct, PHB.
	how can you be sure that the originating system is not cheating?

>wrong can happen, regardless of memory being partioned and protected.

	I guess you are too optimistic.  if you are using align-picky
	architecture CPU for your router, I can panic your router by putting
	some value that is not align-friendly into flow label field as the
	extension header length.

>memory, so "memory access violation" is unlikely.

	I don't understand what you are trying to mean.  regardless from
	read access or write access, your kernel can be tricked into:
	- accessing bits on a wrong boundary
	- accessing bits that are not a real port number
	I can trick the intermediate routers to believe that I'm using
	TCP port 80, while I'm actually using TCP port 22.

>carefully for IPv6, if need be.

	it is very different from IPv4 case.  in IPv4 case, IHL field is the
	one and only field trustable, and there was no ambiguity.  for IPv6
	extension header length, the actual value is detected only by chasing
	header chain.  your addition (of extension header length into flow
	label field) is a non-trustworthy copy of the real value.  if your
	router believes that the value in flow label field, your router will
	get tricked.

>As said above, the security risk is not higher than with the

	I don't believe so.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Aug 2001 09:15:05 +0300 (EEST)

> pseudo-random number as well.

The user does not know which pseudo-random value to choose (2^19 or the
like is lots..) to select to "steal specific kind of traffic", at least
before you have indeed sent legally that kind of traffic and observed
higher priority given to the that flow. If this were based on port numbers
etc., the user could more easily guess/experiment with the behaviour, and
set it as you please.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Aug 2001 08:37:28 -0500

>    I just don't travel in the right circles...

We have deliberately been *very* conservative about defining standard PHBs, since
we want to be very sure about what we standardise. But there are a potentially
infinite number of local-use PHBs. That is why the DSCP value is mappable, and why
the PHB ID was defined, so that local-use PHBs can be registered with IANA and
signalled. The idea here is to stretch the semantics of the PHB ID just a little.

Normal semantics of a PHB ID:

  "This is local-use PHB number 379"

Stretched semantics:

  "This is local-use PHB number 379 and according to our SLA, that gets classified
   as real-time traffic needing at least a 10 Mbit/s rate"

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Aug 2001 08:40:52 -0500

>         how can you be sure that the originating system is not cheating?

As I said, you don't care: they will pay the appropriate tariff for the
PHB they request. It isn't the ISP's problem. 

For the other points, I agree with Itjun and perhaps disagree with Alex -
there are some scary issues in playing with header length etc.

    Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Aug 2001 08:48:05 -0700 (PDT)

> signalled. The idea here is to stretch the semantics of the PHB ID just a little.

Right. Even if the number of PHB's grows beyond
6-8 bits (which seems pretty unlikely to me), in
order to be a real problem you would have to posit
a network/domain which actually wanted to use more
than could be currently mapped into the DSCP. I've
been working on a lot of voip stuff in the last
few years and the number of DSCP's I've heard has
been in the range of about 2 to 5 or 6 that I
recall, with higher end of the range seeming
pretty extravagant.

 >    as real-time traffic needing at least a 10 Mbit/s rate"

Ah. This strikes me as trying to overload the
semantics of DiffServ. Another way to go about
this is to use signaled diffserv (either the
COPS-PR or RSVP varieties) with policers at the
proper edges of the network. That way, the traffic
classes (ie the actual PHB) stays small. 

	    Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Aug 2001 14:39:16 -0500

Michael Thomas wrote:
> semantics of DiffServ. 

Yes. Pretty shameless of me as diffserv co-chair :-)

> Another way to go about

True. But signalling in the flow label is a low overhead approach
(although of course there needs to be an out of band way of
creating the SLA).

    Brian

---

From: Alex Conta <[email-masked]>
Date: Thu, 16 Aug 2001 19:07:09 -0400

itojun,

As Brian already rightfully said, perhaps not with the same words, the
draft promotes the flow label format in the main text, which is the IANA
based value format. As Brian, I believe more in the IANA format. The
flow label formats in the Appendix are presented as possible choices,
each with its advantages and disadvantages, and as a record of such
choices. The draft states that in the Appendix.

The reason I am still arguing the Appendix formats, is for the sake of
fairness and accuracy.

Jun-ichiro itojun Hagino wrote:
> ....

Memory alignment became an access speed issue with certain 64bit
processor/memory architectures, because of the access in 32 or 64bit
"blocks", aligned at 32, or 64bit boundaries, thus possibly requiring
for a byte access, depending the position of the byte in the "block", a
shift of 8, 16, 24, or more bits. But this is far from anything you
describe.

I am afraid "memory alignment violation" is more a result of one's
imagination than reality.

>         router believes that the value in flow label field, your router will

Ultimately, as Brian pointed out, the Network Provider will charge the
customer. The customer, if he/she is the culprit will pay, otherwise,
will pay, and chase the culprit.

For the sake of accuracy, for a flow label format that contains the
length and the host-to-host protocol id, the flow label value should be
set by the IPv6 stack, that is, the KERNEL. The user should only trigger
the use of the label, but the two values - length, protocol id - would
be set by the KERNEL, on "IPv6 output" code path. Both values are known
on packet transmission. The length can be calculated and cached or
stored in a field in the Protocol Control Block, or whatever structure
is representing the communication. 

> >As said above, the security risk is not higher than with the

you are making it sound like there is NO RISK with the pseudo-random
number, and that is NOT TRUE.

Once a pseudo-random flow label has been generated and cached, the risk
of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random
flow label value.

Alex

---

From: Alex Conta <[email-masked]>
Date: Thu, 16 Aug 2001 19:15:32 -0400

Indeed, there is a need for at least one packet of a high QoS level
before one could steal the value of the flow label and use it for a
non-authorized flow
(it is mostly, if not always, known which ports are high QoS level and
which not). 

However, once the pseudo-random number is cached, or stored, the RISK is
not different.
A long flow state time to live obviously helps the wrongdoer.

---

From: Alex Conta <[email-masked]>
Date: Fri, 17 Aug 2001 17:37:40 -0400

Jun-ichiro itojun Hagino wrote:
> 
>        then why you pushed those non-IANA values in the presentation?
>        this is the source of confusion.

You refer to the last 2 slides of the 14 slide presentation, each WITH
BIG TITLES:
OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of the
draft.

Your message title confused me: I thought you've read the draft, and
based your comments on the draft. 

I agree. Certainly less confusion, less nit picking, non-bias, always
helps. 

<...>
> ... have you ever used alignment-picky CPUs like alpha?
> 

at the top of page 27 in the draft, in Appendix A:

"...IPv6 headers are 8byte aligned, therefore the length could be
represented as the number of 8byte
 chunks occupied by the headers, in which case the maximum length would
be 32Kbytes."

With this representation, the receiver would simply shift the value of
the field with 3 bits, thus ensuring a 8 byte alignment on accessing the
TCP/UDP headers.

>... 
>         how can you trust IPv6 stack that is in the possession of end user?
>         they can be hacked up.  the only devices you can trust is those you
>         administer in your diffserv cloud.  you can never trust customers
>         devices.
> 

It seems to me that you are still missing the points made earlier. 

The Diffserv QoS engines in the access routers do a policing
(classification&metering&dropping) that trims the high level QoS traffic
-- hacked by a user, or not -- to the level specified in SLAs, TCAs. So,
a user, at the most, uses up all that was contracted with the ISP, and
paid for, anyway. This is in fact THE BEAUTY of THE MODEL.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 17 Aug 2001 14:12:05 +0900

>imagination than reality.

	you are horribly wrong.  have you ever used alignment-picky CPUs
	like alpha?

>of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random

	I believe there's substantial difference, but okay, I got your point.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Sat, 18 Aug 2001 09:03:19 +0300 (EEST)

> paid for, anyway. This is in fact THE BEAUTY of THE MODEL.

You seem to assume that you would always spoof to get _better_ service.
This may not be the case, especially if you have to pay for the premium
(and ISP would want you to pay more, of course :).  If e.g. some 3G
mobiles were using this mechanism, Bastard Operators might set it so that
some messages (think SMS) are dirty expensive compared to "normal
traffic".  Then, if the user would be able to change the label to get
those for a cheaper price (and perhaps insignificant loss of QoS) and get
billed way less, he might do it.

Also, the idea that an operator might do QoS classification etc. on the
traffic _for free_ (e.g. add "low delay" to dport 22, 23; low cost to nntp
etc.) just to benefit the user(s) is unfamiliar to you?  This is where
"spoofing" becomes annoying, because people don't pay for the extra QoS.
I think this was a basis in "spoofing better QoS capabilities"
discussion.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 18 Aug 2001 18:19:50 +0900

>based your comments on the draft. 

	even if they are in the appendix section, it is still true that
	your idea does not work.  I would like to suggest you to
	drop the appendix A from the next revision of the draft.

>the field with 3 bits, thus ensuring a 8 byte alignment on accessing the

	fair enough, but I really suggest you to drop the section as well,
	as it won't work.

>paid for, anyway. This is in fact THE BEAUTY of THE MODEL.

	you have been saying, in the thread, that the PHB value gets filled
	by the originating end.  so which is the truth?  if the most
	significant bit of the flow label field is the indication of
	"end-to-end/hop-by-hop", say so in the draft.  there's no indication.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Aug 2001 14:34:24 -0500

> billed way less, he might do it.

But at busy hour they may get no service at all so I think they will
still get what they pay for.

> I think this was a basis in "spoofing better QoS capabilities"

Hate to say it, but soft-hearted ISPs who do this will indeed be ripped
off by some of their users. 

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Aug 2001 14:45:56 -0500

itojun,

>         drop the appendix A from the next revision of the draft.

When the WG decides what it wants, we could certainly drop the discussion
of the rejected ideas (but sometimes it is useful to at least list
the rejected ideas, so that we don't have the same discussion again
in 2003).

>         "end-to-end/hop-by-hop", say so in the draft.  there's no indication.

The DSCP MAY be rewritten *anywhere* along the path, typically at an administrative
domain boundary. Even if it is initially set by the source host, it MAY be rewritten
each time the packet goes through a multi-field classifier. Thus, the value is not
altered at every hop, but it may not be e2e either.

The distinction made in the proposal by the MSB is between a pseudo-random 
value as defined in RFC 2460 Appendix A (for intserv) and a non-random value 
(for diffserv). But they are both e2e values, unlike the DSCP. This should
be documented.

  Brian

---

From: Alex Conta <[email-masked]>
Date: Mon, 20 Aug 2001 10:54:16 -0400

Pekka Savola wrote:
> You seem to assume that you would always spoof to get _better_ service [....]

No, I do not assume at all that one would "always" spoof. 

>etc.) just to benefit the user(s) is unfamiliar to you? [...]
>

I do not assume at all that the provider chooses to do a QoS
classification/policing to only help the customer, or that it does it
for free. 

The classification/policing and the rest of QoS, helps also the
provider, it helps maximizing the usage of the provider network, while
optimizing the service that the customers perceive/receive. The customer
is paying usually one bill, that includes everything, the costs for
higher QoS, lower QoS, or non-QoS at all(best effort). 

Regards,
Alex