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:	Tue, 26 Jan 2010 14:02:07 +0000
From:	Dunc <dunc@...onia.org>
To:	Kalle Valo <kalle.valo@....fi>
CC:	David Miller <davem@...emloft.net>, kaber@...sh.net,
	netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: Network QoS support in applications


> 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
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ