[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B5EF5DF.2070005@lemonia.org>
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