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:	Tue, 26 Jan 2010 22:54:01 +0100
From:	"Edgar E. Iglesias" <edgar.iglesias@...il.com>
To:	Kalle Valo <kalle.valo@....fi>
Cc:	Dunc <dunc@...onia.org>, 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 Tue, Jan 26, 2010 at 04:27:29PM +0200, Kalle Valo wrote:
> Dunc <dunc@...onia.org> writes:
> 
> > 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?
> 
> Nobody. That would a bug in the application which should be fixed.
> Badly behaving applications can disrupt the network, with or without
> QoS support. So no need to blame QoS for this.

Fixing the app is not always an alternative, the damage may already
be done. You simply cannot always trust all the devices.

And, AFAIK you can setup "QoS" networks where a user's traffic won't
disturb others.

> And if the network doesn't want to trust applications, it's free to do
> so. Nothing prevents that. And based on the discussion so far, the
> networks already ignore QoS classifations coming from other network
> realms.

>From my experience, you have a mix of devices you trust and devices you
don't trust. For untrusted devices you want to classify and re-tag
their traffic as it enters your cloud, regardless of whatever the dev
tagged it with.

For trusted devices, typically stuff that is under the net admins control,
you let the device itself put the tags. This can be very useful for ex when
even advanced matching won't be able to differentiate between different
flows. For example, try to differentiate two ssl flows based on their
contents. Only the source can.

IMO what apps should be doing is setting the DSCP to a user configurable
value (config file or cmd line switch etc). This way people can choose DSCP
to whatever makes sense in their particular network. The default value
is of less interest.

WRT L3 vs L2, I think apps should normally be tagging by setting the DSCP
field. The kernel should provide configurable mappings between DSCP and
what ever L2 QoS that is available on the egress interface. As the packet
jumps and gets routed, the DSCP value gets remapped two every links
particular L2 "QoS" that matches the DSCP. After all, apps shouldn't need to
know their hooked up to a 802.11, wired ethernet or what ever is on the
route to the peer...

AFAIK, Linux already makes all of this perfectly possible.

My 2 cents..

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