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]

Message-ID: <39575e70388bb2ea58dd36b9061d5055@chewa.net>
Date:	Tue, 26 Jan 2010 15:43:01 +0100
From:	Rémi Denis-Courmont <remi@...lab.net>
To:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: Network QoS support in applications

On Tue, 26 Jan 2010 15:47:41 +0200, Kalle Valo <kalle.valo@....fi> wrote:
> But that's just because of mistakes with DiffServ and other QoS
> "frameworks". They didn't bother to specify how applications should
> use these. And what matters here IMHO.

TOS lets the application specify whether they want low-delay (interactive
low bandwidth traffic), high bandwidth (bulk traffic), high reliability or
low cost. It's surely vague, but anything "uniform" solution is bound to be
vague. Some applications *do* set those fields, or provide options to set
them up. And contrary to SO_PRIORITY, it *can* be made to work for
non-local queues, if the applications are trusted.

I am afraid it's too late for anything more uniform at the socket API
level. Even fewer developers would bother to support Linux>=2.6.3x-specific
options, than TOS/TCLASS.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

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