Re: setsockopt(IP_TOS) being privileged or distinct capability?

[Philip Prindeville <philipp_subx@redfish-solutions.com>]

On 7/5/10 8:07 PM, Hagen Paul Pfeifer wrote:
> * Philip Prindeville | 2010-07-05 12:04:31 [-0600]:
>
>    
>> I understand that.  That's part of the reason that I've submitted
>> patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>> etc.  There is pressure within certain technical groups to get ISP's
>> to voluntarily implement RFC-4594... that's the carrot.  The stick
>> being FCC heavy-handed regulation of the ISP's if they don't.
>>      
> Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
> operation? At the end the user/service is still required to set his service
> class, but this time with CAP_NET_ADMIN. Do you think that Service
> Providers/Transit Providers trust (and this is the critical aspect) customers
> based on some IP flags - this is extreme unlikely. 99% of users have
> effective CAP_NET_ADMIN capabilities - and you cannot stop using them.
>    

QoS is expensive to implement, since it requires a lot more inspection 
of the packet, multiple queues, bandwidth reservation, etc.

ISP's are going to look for an excuse not to implement it.

Having it be exploited by users is another arrow in their quill to not 
implement it.

Yes, most users have admin/privileged rights on their machines, but 
don't know enough to exploit that.

Whatever makes it harder to abusively exploit QoS seems like a good 
idea.  Harder.  Not impossible.

"Stopping them" was never the objective.

> Service Providers/Transit Providers will trust customers who pays more and
> then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
> other customers will be treated normal, with zeroed DSCP. It makes no sense
> for ISP's to shift the trust aspect to the customer side.
>
> HGN
>
>
>    

Alas there's more to it than that: the movement is to make QoS be 
ubiquitous for all SLA's of broadband.

I'd argue that it makes no sense for them not to trust it:  SDP/RTP 
packets are hard to identify as such without peaking into the 
accompanying SIP conversation... which drives up the cost of their 
required infrastructure to handle QoS even more.

Besides, if I deploy a new protocol that uses RTP or leverages QoS, I'd 
have to wait for the ISP to update their network with knowledge of that 
protocol in order to handle it properly... given the glacial pace that 
at which ISP's certify and deploy software updates, configuration 
changes, etc. I don't want to have to wait months or years for them to 
play catch-up.

What's more, if I'm running SIP over TLS over TCP, they can't peek into 
the stream anyway to figure out what UDP ports I'm using for SDP.

So I can sacrifice control, privacy, or timeliness... or they can simply 
trust my QoS markings.

But what's the downside of their trusting my markings, anyway?

Let's say that I have 7mb/s DSL, and with that standard base profile 
comes 240kb/s EF policing, 512kb/s AF4x, etc.  Further let's suppose 
that I exceed my SLA: they could either downgrade the excess to the next 
lowest bin, or discard it... Hence I'm highly incentivized to remain 
within my agreed SLA envelope.