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

["Henry Sinnreich" <hsinnrei at adobe.com>]

Thanks Paul, well said!

What worries me as a paying customer for both Vonage and Skype (chat,
international + video to see grandson) is my cable or DSL provider
should not give them _de-prioritized_ packet handling over their own
VoIP.

So far both Comcast and now Time Warner have provided us excellent
broadband service, but reading some statements coming out from Telco's
make one apprehensive.

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
Sent: Friday, May 11, 2007 7:27 PM
To: Dale.Worley at comcast.net
Cc: sipping at ietf.org
Subject: 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


_______________________________________________
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