netdev - Re: Network QoS support in applications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Mar 2010 12:21:11 -0700
From:	"Philip A. Prindeville" <philipp_subx@...fish-solutions.com>
To:	Dunc <dunc@...onia.org>
CC:	Kalle Valo <kalle.valo@....fi>, David Miller <davem@...emloft.net>,
	kaber@...sh.net, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: Network QoS support in applications

On 01/26/2010 07:02 AM, Dunc wrote:
>   
>> And you are perfectly right, as always. My choise of using the word
>> "universal" was bad. With word "universal" I meant to use same network
>> QoS API with different network technologies: ethernet, wi-fi,
>> bluetooth etc.
>>
>> But we don't need to solve everything in one go, instead we can make
>> small steps. The first step is to start pushing applications to
>> classify their streams. That's the enabler to get some sort of QoS
>> support, at least to inside kernel and to the next hop. With luck, in
>> future it might get more widely used.
>>
>> I was hoping to base the classification on some standard, but there
>> doesn't really seem to be one which would specify a complete solution.
>> But that's ok, we can always create a de facto standard :)
>>
>> I'm curious how other operation systems handle this? Or is it a
>> similar situation, nobody just doesn't use QoS for anything?
>>
>>     
> If applications set the QoS values, the who's to stop someone (for
> example) writing a bittorrent client that marks all packets for the
> highest priority as if they were VoIP or something? At this point all
> the good work done in the applications is useless and the network admin
> is going to have to not trust the QoS values and then attempt to
> classify traffic by themselves, so it was all a waste of time.
>
> It's probably better to just always leave it up to the network devices IMHO.
>
> Cheers,
>
> Dunc
>
>   

I disagree.

Some protocols are *very* hard to classify without looking into the
application layer, which I have no interest in having network devices do
(especially since in a multipath environment, they might not even see
the entire flow).

RTP, FTP-DATA, and TFTP are all very hard to classify because they don't
use fixed port numbers.

And even if you identify RTP, you still don't know if it's voice or
video since that is signaled out-of-band.

And yes, there will always be misbehaving users.  They are a fact of
life.  That doesn't mean we should lobotomize the network.  We don't
have an authentication mechanism on ICMP Redirects or Source-Quench, for
instance.  Nor is ARP authenticated.

BTW:  Why not have Linux do DSCP/CS to 802.1p priority mapping on
Ethernet drivers "out-of-the-box", regardless of whatever 802.1p tagging
is actually being used or not (i.e. make it implied on the sending
end-system).

-Philip

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html