All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont" <remi@remlab.net>
To: netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: Network QoS support in applications
Date: Tue, 26 Jan 2010 15:43:01 +0100	[thread overview]
Message-ID: <39575e70388bb2ea58dd36b9061d5055@chewa.net> (raw)
In-Reply-To: <87my01m0zm.fsf@purkki.valot.fi>


On Tue, 26 Jan 2010 15:47:41 +0200, Kalle Valo <kalle.valo@iki.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


WARNING: multiple messages have this Message-ID (diff)
From: "Rémi Denis-Courmont" <remi@remlab.net>
To: netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: Network QoS support in applications
Date: Tue, 26 Jan 2010 15:43:01 +0100	[thread overview]
Message-ID: <39575e70388bb2ea58dd36b9061d5055@chewa.net> (raw)
In-Reply-To: <87my01m0zm.fsf@purkki.valot.fi>


On Tue, 26 Jan 2010 15:47:41 +0200, Kalle Valo <kalle.valo@iki.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


  parent reply	other threads:[~2010-01-26 14:50 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26  8:27 Network QoS support in applications Kalle Valo
2010-01-26  8:27 ` Kalle Valo
2010-01-26 11:30 ` Patrick McHardy
2010-01-26 11:30   ` Patrick McHardy
2010-01-26 11:51   ` Kalle Valo
2010-01-26 11:51     ` Kalle Valo
2010-01-26 11:59     ` Patrick McHardy
2010-01-26 11:59       ` Patrick McHardy
2010-01-26 12:16     ` David Miller
2010-01-26 12:16       ` David Miller
2010-01-26 12:56       ` Kalle Valo
2010-01-26 13:06         ` David Miller
2010-01-26 13:47           ` Kalle Valo
2010-01-26 13:47             ` Kalle Valo
2010-01-26 14:02             ` Dunc
2010-01-26 14:27               ` Kalle Valo
2010-01-26 14:27                 ` Kalle Valo
2010-01-26 21:54                 ` Edgar E. Iglesias
2010-01-26 21:54                   ` Edgar E. Iglesias
2010-01-27  7:11                   ` Kalle Valo
2010-01-27  1:57               ` Zhu Yi
2010-01-27 13:24               ` Benny Amorsen
2010-03-11 19:21               ` Philip A. Prindeville
2010-03-11 19:27                 ` David Miller
2010-03-11 19:27                   ` David Miller
2010-03-11 19:29                   ` Philip A. Prindeville
2010-03-11 19:29                     ` Philip A. Prindeville
2010-05-19  0:04                     ` Philip A. Prindeville
2010-05-31 19:30                       ` Ben Gardiner
2010-05-31 19:30                         ` Ben Gardiner
2010-05-31 20:28                         ` Philip Prindeville
2010-01-26 14:43             ` Rémi Denis-Courmont [this message]
2010-01-26 14:43               ` Rémi Denis-Courmont
2010-01-26 13:06         ` Henning Rogge
2010-01-26 13:06           ` Henning Rogge
2010-01-27  6:59           ` Kalle Valo
2010-01-26 15:29       ` Steven Blake
2010-01-27  7:03         ` Kalle Valo
2010-01-27 16:18 ` Olaf van der Spek
2010-01-27 16:26   ` Greg Oliver
2010-03-11 18:56 ` Philip A. Prindeville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39575e70388bb2ea58dd36b9061d5055@chewa.net \
    --to=remi@remlab.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.