[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] I-D on service identification now available



I agree with Dale that this *can* be used in a way that equitably assigns cost for resources consumed. I just don't see how to ensure it isn't abused.

The obvious case that has come up recently is whether the SPs that provide *access* should be charging the big web server companies, such as Google, for better QoS to the access customer.

And I think the answer to that is "it depends".

If a SP customer has already paid for access, with some bandwidth guarantees, then Google should not have to pay the SP again in order for the customer to use that bandwidth to send or receive content from Google.

But, if the customer would like to receive content using bandwidth over and above what he has contracted for, then its not unreasonable to set up a way to arrange for somebody to pay for that. There are a number of possibilities that all seem plausible:
- the customer could upgrade his level of service, paying more per
month to get a higher bandwidth guarantee.


- the SP could bill the customer one-time charges for use of extra
  bandwidth over and above is guarantee.

- the SP could bill Google  a one-time charge for providing
  extra access bandwidth to the customer.

- the SP could establish a service contract with Google which gives
  Google the right to use bandwidth in excess of customer's contracted
  bandwidth.

What I don't consider reasonable is if the SP wants to charge Google to send data to the customer *within* the bandwidth guarantees covered by the customer's contract with the SP. I fear that is what is desired. It seems that the SPs want to establish contracts with customers that appear to provide QoS guarantees, but in fact do not. Then they want to charge on top of that to actually provide QoS.

If there was a way for Google to pay the SP for service from a SP in excess of what the customer has contracted for, presumably Google could bill the customer back for that. This would be very similar to the way Amazon bills customers various categories of shipping.

	Paul

Dale.Worley at comcast.net wrote:
   From: "Henry Sinnreich" <hsinnrei at adobe.com>

   ... After all QoS is an evil tool ...

IMHO, QoS is a much more complex area than it first seems.  As the
IAB's I-D points out, QoS can be used to reduce Internet transparency
for undesirable means.  But on the other hand, the proper use of QoS
is very useful in situations where the demand for bandwidth exceeds
the supply, and if skillfully applied, can be used to place the costs
of infrastructure deployment on the users that require the additional
infrastructure.

Consider the case of someone who set up an open Wi-Fi network and
within a few days discovered that someone had attached a Bit Torrent
server to it.  As Internet applications become more sophisticated,
it's always possible to build applications that can consume more
bandwidth than is available.

If QoS is properly applied and priced, it becomes like
congestion-pricing of roads -- most of the costs are borne by the
users whose demands require adding infrastructure, while users willing
to avoid making those demands use the service for much, much lower
prices.  (Which will reduce the need for explicit subsidies for
poverty-stricken users.)

How do you get the good and avoid the bad?  As far as I can see, if a
service provider has a free hand and a monopoly, they can impose all
of the evils of QoS, even if there is no QoS architecture in the
protocols.  But if there is adequate competition, or regulation that
produces the results that adequate competition would provide, QoS
limitations and pricing would be driven by the impact of usage on
infrastructure costs.

Dale


_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP