All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Kalle Valo <kalle.valo@iki.fi>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: Network QoS support in applications
Date: Tue, 26 Jan 2010 12:30:28 +0100	[thread overview]
Message-ID: <4B5ED254.7010104@trash.net> (raw)
In-Reply-To: <87k4v5nuej.fsf@purkki.valot.fi>

Kalle Valo wrote:
> Hello,
> 
> I have been trying to understand how applications should use network
> QoS. My interest have been mostly from wireless perspective,
> especially how to utilise WMM and U-APSD properly, but naturally this
> applicable to all networks.
> 
> I have done some research about this, but I haven't managed to get
> anywhere. For example, from my point of view DiffServ is just one big
> mess and I can't see how in practise it can help applications.
> 
> I wrote a small wiki page to sum up my findings:
> 
> http://wireless.kernel.org/en/developers/Documentation/qos
> 
> I would like to clear up all this by and I'm willing to write a
> document for application developers about network QoS. But I need help
> to understand what's the proper way to mark different QoS
> prioritities.
> 
> In the wiki page I have tried to come up with different possible
> solutions (copied below), but I'm sure there are even more ways.
> 
> Please comment. I would like to get some understanding about this.
> 
> 
> ----------------------------------------------------------------------
> Solution 1: SO_PRIORITY with values 0-7
> 
> Easy, applications need to just use setsockopt() and be done with it.
> It's unknown how widely supported values 0-7 are and the exact meaning
> of them, but at least they make sense (0 default, 1 lowest priority
> and 7 highest priority). The problem is that the priority is used only
> in the first link, rest of the route is not able to benefit from the
> classification.
> 
> Pros:
> 
>     * easy for applications
>     * works with both IPv4 and IPv6 
> 
> Cons:
> 
>     * only visible in in the first L2 link, not visible to upper
>       layers (IP)
>     * no well defined meaning for the priority values 
> 
> Solution 2: SO_PRIORITY with values 256-263

You can actually encode any class handle in SO_PRIORITY, all classful
qdiscs support classification based on this.

WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
To: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Network QoS support in applications
Date: Tue, 26 Jan 2010 12:30:28 +0100	[thread overview]
Message-ID: <4B5ED254.7010104@trash.net> (raw)
In-Reply-To: <87k4v5nuej.fsf-ySPBbPOLdCfMApvqMRVM/A@public.gmane.org>

Kalle Valo wrote:
> Hello,
> 
> I have been trying to understand how applications should use network
> QoS. My interest have been mostly from wireless perspective,
> especially how to utilise WMM and U-APSD properly, but naturally this
> applicable to all networks.
> 
> I have done some research about this, but I haven't managed to get
> anywhere. For example, from my point of view DiffServ is just one big
> mess and I can't see how in practise it can help applications.
> 
> I wrote a small wiki page to sum up my findings:
> 
> http://wireless.kernel.org/en/developers/Documentation/qos
> 
> I would like to clear up all this by and I'm willing to write a
> document for application developers about network QoS. But I need help
> to understand what's the proper way to mark different QoS
> prioritities.
> 
> In the wiki page I have tried to come up with different possible
> solutions (copied below), but I'm sure there are even more ways.
> 
> Please comment. I would like to get some understanding about this.
> 
> 
> ----------------------------------------------------------------------
> Solution 1: SO_PRIORITY with values 0-7
> 
> Easy, applications need to just use setsockopt() and be done with it.
> It's unknown how widely supported values 0-7 are and the exact meaning
> of them, but at least they make sense (0 default, 1 lowest priority
> and 7 highest priority). The problem is that the priority is used only
> in the first link, rest of the route is not able to benefit from the
> classification.
> 
> Pros:
> 
>     * easy for applications
>     * works with both IPv4 and IPv6 
> 
> Cons:
> 
>     * only visible in in the first L2 link, not visible to upper
>       layers (IP)
>     * no well defined meaning for the priority values 
> 
> Solution 2: SO_PRIORITY with values 256-263

You can actually encode any class handle in SO_PRIORITY, all classful
qdiscs support classification based on this.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-01-26 11:30 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 [this message]
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
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=4B5ED254.7010104@trash.net \
    --to=kaber@trash.net \
    --cc=kalle.valo@iki.fi \
    --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.