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 14:56:50 +0200
From:	Kalle Valo <kalle.valo@....fi>
To:	David Miller <davem@...emloft.net>
Cc:	kaber@...sh.net, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: Network QoS support in applications

David Miller <davem@...emloft.net> writes:

> From: Kalle Valo <kalle.valo@....fi>
> Date: Tue, 26 Jan 2010 13:51:55 +0200
>
>> Let's take a bittorrent client as an example. The traffic it generates
>> is not important and it doesn't matter if bittorrent packets have
>> lower priority compared to other streams. What SO_PRIORITY value
>> should all bittorrent clients to use to mark their packets as low
>> priority (for example background class from IEEE 802.1d Annex G).
>
> This is a local policy decision.
>
> There is no universal way of doing any of this, really.

In my opinion we already now need a universal solution for the user
space applications to classify their streams. Having a local solution
doesn't get us far, people don't want to configure their laptops or
phones, they just want to use them :)

Having a well defined API for this makes it easier for everyone. Also
proprietary applications, like skype, can make use of QoS.

It doesn't matter how we map these internally in kernel, but the
interface to user space needs to be documented and maintained. I'm
willing to work on this, but we first need a concensus for the method.

I'm leaning towards using IPv4 DS/TOS and IPv6 Traffic Class fields
using IEEE 802.1d values. That way, with luck, the class of the packet
is visible even more than one hop. In fact cfg80211/mac80211 is
already doing this for IPv4:

/* Given a data frame determine the 802.1p/1d tag to use. */
unsigned int cfg80211_classify8021d(struct sk_buff *skb)
{
        unsigned int dscp;

        /* skb->priority values from 256->263 are magic values to
         * directly indicate a specific 802.1d priority.  This is used
         * to allow 802.1d priority to be passed directly in from VLAN
         * tags, etc.
          */
          if (skb->priority >= 256 && skb->priority <= 263)
             return skb->priority - 256;

             switch (skb->protocol) {
             case htons(ETH_P_IP):
                  dscp = ip_hdr(skb)->tos & 0xfc;
                       break;
                       default:
                        return 0;
                        }

                        return dscp >> 5;
}

http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=net/wireless/util.c;h=be2ab8c59e3a9806425b2b958d87dfe50d80111d;hb=HEAD#l598

So the idea is that the three left most bits (Class Selector
Codepoints from DiffServ RFC 2474) would contain these values from
IEEE 802.1d-2004 Annex G:

0 best effort
1 background
2 (spare)
3 excellent effort
4 controlled load
5 video
6 voice
7 network control

What do people think of this? 

Feel free to flame, it was -20 C (-4 F) this morning. I would need
some warmth here :)

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