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 16:27:29 +0200
From:	Kalle Valo <kalle.valo@....fi>
To:	Dunc <dunc@...onia.org>
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

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.

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.

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

Because of one badly behaving application? I think that's a bit
extreme. If QoS API brings benefits to the user (for example in this
case bittorrent giving bandwith to more important streams), most
probably applications try to get it right.

> It's probably better to just always leave it up to the network devices IMHO.

If we are happy with the current situation, sure, no need to do
anything. But if we want to improve network services, we need to start
to do something about this.

I want to emphasise that we shouldn't look at this just from the core
network point of view, but with a broader look. We have now different
network technologies and devices where Linux is used. We should not
just look at this from a point where a Linux workstation (or router)
is connected with a fast access to Internet. For example, I want to
have my ssh terminal connection higher priority compared to emails
downloading background on a slow cellular network.

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