Network QoS support in applications

Network QoS support in applications

[Kalle Valo]

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

mac80211 uses these values to map the packets to DSCP classes. Most
probably non other stack or driver (even non-wifi ones) use these
values. Otherwise similar as Solution 1.

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
    * using values over 256 is not intuitive 

Solution 3: IPv4 DSCP field with values 0-7

Most, if not all, wifi drivers should use it. And, in theory, the
receiver should also benefit from the classification, unless ISPs
modify it of course. But the standardisation for IPv4 QoS bits is a
mess.

Pros:

    * visible in IP layer (but ISPs change the value often?) 

Cons:

    * applications need to handle IPv4 and IPv6 separately 
----------------------------------------------------------------------

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

Re: Network QoS support in applications

[Patrick McHardy]

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

Re: Network QoS support in applications

[Kalle Valo]

Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:

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

But what values should I use in an application? There seems to n+1
different ways to do it, but they all would be specific to my own
setup.

I'm after a universal solution, so that there is no need to modify
applications every time. I would assume that we have a set of rules
for this. If not, we definitely need one.

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

Another example is a VoIP application. The packets need to have as low
delay as possible, so they need to be prioritised very high (for
example voice class from 802.1d). What value should such application
use?

Or should applications use something else than SO_PRIORITY?

Any help is greatly welcomed here :)

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

Re: Network QoS support in applications

[Patrick McHardy]

Kalle Valo wrote:
> Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:
> 
>>> 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.
> 
> But what values should I use in an application? There seems to n+1
> different ways to do it, but they all would be specific to my own
> setup.

In case of classful qdisc classification, the values need to
match the class handles.

> I'm after a universal solution, so that there is no need to modify
> applications every time. I would assume that we have a set of rules
> for this. If not, we definitely need one.

Classful qdisc configuration is done by the administrator, so
there is no universal solution.

> 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).
> 
> Another example is a VoIP application. The packets need to have as low
> delay as possible, so they need to be prioritised very high (for
> example voice class from 802.1d). What value should such application
> use?

If the device is using the default pfifo_fast qdisc, you
can use values 6 and 7 to map to band 0 (highest priority),
0 and 8-15 to map to band 1 and 1-3 and 5 to map to band 2.

For manually set up qdisc hierarchies you need to ask the
user to specify a priority (or class handle) value.

> Or should applications use something else than SO_PRIORITY?
> 
> Any help is greatly welcomed here :)
> 

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

Re: Network QoS support in applications

[David Miller]

From: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org>
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.
--
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

Re: Network QoS support in applications

[Kalle Valo]

David Miller <davem@davemloft.net> writes:

> From: Kalle Valo <kalle.valo@iki.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

Re: Network QoS support in applications

[David Miller]

From: Kalle Valo <kalle.valo@iki.fi>
Date: Tue, 26 Jan 2010 14:56:50 +0200

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

And similarly your organization's administartion doesn't want to
prioritize bittorrent traffic a specific fixed way just because your
application sets some bits in the TOS field of it's packets.

Prioritization policies have no meaning outside of your local realm,
and that's just a fact of life.

So what typically happens is that applications do nothing.

And machines on the ingress to a network realm change the TOS based
field upon classification decisions made by parsing the packet by the
router/firewall/whatever.

The packet gets QoS treatment within the realm, but completely
determined by local policy within that realm.

And then on egress from the realm the TOS field has absolutely
no meaning at all to the next network segment.

Re: Network QoS support in applications

[Kalle Valo]

David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:

> From: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org>
> Date: Tue, 26 Jan 2010 14:56:50 +0200
>
>> 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 :)
>
> And similarly your organization's administartion doesn't want to
> prioritize bittorrent traffic a specific fixed way just because your
> application sets some bits in the TOS field of it's packets.
>
> Prioritization policies have no meaning outside of your local realm,
> and that's just a fact of life.

Yes, that's what I have understood.

> So what typically happens is that applications do nothing.

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.

> And machines on the ingress to a network realm change the TOS based
> field upon classification decisions made by parsing the packet by the
> router/firewall/whatever.
>
> The packet gets QoS treatment within the realm, but completely
> determined by local policy within that realm.
>
> And then on egress from the realm the TOS field has absolutely
> no meaning at all to the next network segment.

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?

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

Re: Network QoS support in applications

[Dunc]

> 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

Re: Network QoS support in applications

[Kalle Valo]

Dunc <dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.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 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

Re: Network QoS support in applications

[Edgar E. Iglesias]

On Tue, Jan 26, 2010 at 04:27:29PM +0200, Kalle Valo wrote:
> Dunc <dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.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.

Fixing the app is not always an alternative, the damage may already
be done. You simply cannot always trust all the devices.

And, AFAIK you can setup "QoS" networks where a user's traffic won't
disturb others.


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

>From my experience, you have a mix of devices you trust and devices you
don't trust. For untrusted devices you want to classify and re-tag
their traffic as it enters your cloud, regardless of whatever the dev
tagged it with.

For trusted devices, typically stuff that is under the net admins control,
you let the device itself put the tags. This can be very useful for ex when
even advanced matching won't be able to differentiate between different
flows. For example, try to differentiate two ssl flows based on their
contents. Only the source can.

IMO what apps should be doing is setting the DSCP to a user configurable
value (config file or cmd line switch etc). This way people can choose DSCP
to whatever makes sense in their particular network. The default value
is of less interest.

WRT L3 vs L2, I think apps should normally be tagging by setting the DSCP
field. The kernel should provide configurable mappings between DSCP and
what ever L2 QoS that is available on the egress interface. As the packet
jumps and gets routed, the DSCP value gets remapped two every links
particular L2 "QoS" that matches the DSCP. After all, apps shouldn't need to
know their hooked up to a 802.11, wired ethernet or what ever is on the
route to the peer...

AFAIK, Linux already makes all of this perfectly possible.

My 2 cents..

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

Re: Network QoS support in applications

[Kalle Valo]

"Edgar E. Iglesias" <edgar.iglesias@gmail.com> writes:

> IMO what apps should be doing is setting the DSCP to a user configurable
> value (config file or cmd line switch etc). This way people can choose DSCP
> to whatever makes sense in their particular network. The default value
> is of less interest.

I have to disagree here. Most of the people are not that interested
configuring their applications, they just want to use them. I see that
having this configurable would be just an excuse for not having a good
default value.

Also it just doesn't scale if every user has to start configuring all
network applications they use. IMHO this all should work "Out of Box".

> WRT L3 vs L2, I think apps should normally be tagging by setting the DSCP
> field. The kernel should provide configurable mappings between DSCP and
> what ever L2 QoS that is available on the egress interface. As the packet
> jumps and gets routed, the DSCP value gets remapped two every links
> particular L2 "QoS" that matches the DSCP. After all, apps shouldn't need to
> know their hooked up to a 802.11, wired ethernet or what ever is on the
> route to the peer...

With this one I fully agree. I think this is the way we should do
this.

> AFAIK, Linux already makes all of this perfectly possible.

Yes, it's possible but not widely used because people don't know about
this. We need to provide documentation and then push applications to
use this.

> My 2 cents..

Thank you very much, much appreciated.

-- 
Kalle Valo

Re: Network QoS support in applications

[Zhu Yi]

On Tue, 2010-01-26 at 22:02 +0800, Dunc wrote:
> 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.

The QoS values an application sets can be viewed as "hints". It is still
the network admin's choice to use it or not. For example, as a network
admin for an Internet router, you don't want to trust any QoS values
from ingress. But as a smart phone owner, you probably want to trust the
applications running on it. For end users on noncritical devices,
requiring them to do traffic mapping themselves is too much. IMO, having
a way for the applications to specify the traffic priority they _wish_
to have is useful.

Thanks,
-yi

Re: Network QoS support in applications

[Benny Amorsen]

Dunc <dunc@lemonia.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?

Nothing, but nothing stops them from writing a bittorrent client which
does "optimistic ACK" either. Yet noone seems to bother.

Also, bittorrent marked as EF could easily get hit by a "don't queue
voice packets, just drop instead" policy. Late voice packets are useless
and might as well be dropped, but TCP streams like bittorrent react
badly to packet loss.

All in all there is little incentive for people to game the system.
Should it happen anyway, network administrators have plentiful tools for
fixing it, up to and including ip link set dev whatever down.


/Benny

Re: Network QoS support in applications

[Philip A. Prindeville]

On 01/26/2010 07:02 AM, Dunc wrote:
>   
>> 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
>
>   

I disagree.

Some protocols are *very* hard to classify without looking into the
application layer, which I have no interest in having network devices do
(especially since in a multipath environment, they might not even see
the entire flow).

RTP, FTP-DATA, and TFTP are all very hard to classify because they don't
use fixed port numbers.

And even if you identify RTP, you still don't know if it's voice or
video since that is signaled out-of-band.

And yes, there will always be misbehaving users.  They are a fact of
life.  That doesn't mean we should lobotomize the network.  We don't
have an authentication mechanism on ICMP Redirects or Source-Quench, for
instance.  Nor is ARP authenticated.

BTW:  Why not have Linux do DSCP/CS to 802.1p priority mapping on
Ethernet drivers "out-of-the-box", regardless of whatever 802.1p tagging
is actually being used or not (i.e. make it implied on the sending
end-system).

-Philip

Re: Network QoS support in applications

[David Miller]

From: "Philip A. Prindeville" <philipp_subx-9z15yex7P+UJvtFkdXX2HpqQE7yCjDx5@public.gmane.org>
Date: Thu, 11 Mar 2010 12:21:11 -0700

> And yes, there will always be misbehaving users.  They are a fact of
> life.  That doesn't mean we should lobotomize the network.  We don't
> have an authentication mechanism on ICMP Redirects or Source-Quench,

Which is why most networks block those packets from the outside.

> Nor is ARP authenticated.

Which is why people control who can plug into their physical
network.

None of the things you are saying support the idea of having
applications decide what the DSCP marking should be.
--
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

Re: Network QoS support in applications

[Philip A. Prindeville]

On 03/11/2010 12:27 PM, David Miller wrote:
> From: "Philip A. Prindeville" <philipp_subx-9z15yex7P+UJvtFkdXX2HpqQE7yCjDx5@public.gmane.org>
> Date: Thu, 11 Mar 2010 12:21:11 -0700
> 
>> And yes, there will always be misbehaving users.  They are a fact of
>> life.  That doesn't mean we should lobotomize the network.  We don't
>> have an authentication mechanism on ICMP Redirects or Source-Quench,
> 
> Which is why most networks block those packets from the outside.
> 
>> Nor is ARP authenticated.
> 
> Which is why people control who can plug into their physical
> network.
> 
> None of the things you are saying support the idea of having
> applications decide what the DSCP marking should be.


Does "decide what the DSCP marking should be" include complying to the recommendations of RFC-4594?

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

Re: Network QoS support in applications

[Philip A. Prindeville]

On 03/11/2010 12:29 PM, Philip A. Prindeville wrote:
> On 03/11/2010 12:27 PM, David Miller wrote:
>   
>> From: "Philip A. Prindeville" <philipp_subx@redfish-solutions.com>
>> Date: Thu, 11 Mar 2010 12:21:11 -0700
>>
>>     
>>> And yes, there will always be misbehaving users.  They are a fact of
>>> life.  That doesn't mean we should lobotomize the network.  We don't
>>> have an authentication mechanism on ICMP Redirects or Source-Quench,
>>>       
>> Which is why most networks block those packets from the outside.
>>
>>     
>>> Nor is ARP authenticated.
>>>       
>> Which is why people control who can plug into their physical
>> network.
>>
>> None of the things you are saying support the idea of having
>> applications decide what the DSCP marking should be.
>>     
>
> Does "decide what the DSCP marking should be" include complying to the recommendations of RFC-4594?
>   

If anyone cares, here's an update:

I've submitted patches for QoS configuration for:

APR/Apache (stalled);
Proftpd (committed);
Openssh (pending review);
Firefox/Thunderbird (reviewed and on-track for commit);
Cyrus (committed);
Sendmail (submittted and acknowledged, but not yet reviewed);
Curl (stalled);

All, as per the request of the maintainers, default to either no QoS
markings or previous RFC-791 QoS markings if that's what they already
supported (Proftpd and Openssh).

If anyone can think of anything else that needs to be supported to
impact a significant portion of network (or enterprise intranet)
traffic, please call it out.

And if anyone wants to see if they can help get Apache unstalled (it's
mostly an autoconf issue with Solaris that's holding things up), please
give me a holler offline.

Thanks.

Re: Network QoS support in applications

[Ben Gardiner]

On Tue, May 18, 2010 at 8:04 PM, Philip A. Prindeville
<philipp-9z15yex7P+UJvtFkdXX2HpqQE7yCjDx5@public.gmane.org> wrote:
> On 03/11/2010 12:29 PM, Philip A. Prindeville wrote:
>> On 03/11/2010 12:27 PM, David Miller wrote:
>>
>>> From: "Philip A. Prindeville" <philipp_subx-9z15yex7P+UJvtFkdXX2HpqQE7yCjDx5@public.gmane.org>
>>> Date: Thu, 11 Mar 2010 12:21:11 -0700
>>>
>>>
>>>> And yes, there will always be misbehaving users.  They are a fact of
>>>> life.  That doesn't mean we should lobotomize the network.  We don't
>>>> have an authentication mechanism on ICMP Redirects or Source-Quench,
>>>>
>>> Which is why most networks block those packets from the outside.
>>>
>>>
>>>> Nor is ARP authenticated.
>>>>
>>> Which is why people control who can plug into their physical
>>> network.
>>>
>>> None of the things you are saying support the idea of having
>>> applications decide what the DSCP marking should be.
>>>
>>
>> Does "decide what the DSCP marking should be" include complying to the recommendations of RFC-4594?
>>
>
> If anyone cares, here's an update:
>
> I've submitted patches for QoS configuration for:
>
> APR/Apache (stalled);
> Proftpd (committed);
> Openssh (pending review);
> Firefox/Thunderbird (reviewed and on-track for commit);
> Cyrus (committed);
> Sendmail (submittted and acknowledged, but not yet reviewed);
> Curl (stalled);
>
> All, as per the request of the maintainers, default to either no QoS
> markings or previous RFC-791 QoS markings if that's what they already
> supported (Proftpd and Openssh).
>
> If anyone can think of anything else that needs to be supported to
> impact a significant portion of network (or enterprise intranet)
> traffic, please call it out.

wget [1], like curl, is used for downloads of artifacts by some build systems.

[1] http://www.gnu.org/software/wget/

-- 
Ben Gardiner
Nanometrics Inc.
+1 (613) 592-6776 x239
http://www.nanometrics.ca
--
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

Re: Network QoS support in applications

[Philip Prindeville]

On 5/31/10 1:30 PM, Ben Gardiner wrote:
> On Tue, May 18, 2010 at 8:04 PM, Philip A. Prindeville
> <philipp@redfish-solutions.com>  wrote:
>    
>> On 03/11/2010 12:29 PM, Philip A. Prindeville wrote:
>>      
>>> On 03/11/2010 12:27 PM, David Miller wrote:
>>>
>>>        
>>>> From: "Philip A. Prindeville"<philipp_subx@redfish-solutions.com>
>>>> Date: Thu, 11 Mar 2010 12:21:11 -0700
>>>>
>>>>
>>>>          
>>>>> And yes, there will always be misbehaving users.  They are a fact of
>>>>> life.  That doesn't mean we should lobotomize the network.  We don't
>>>>> have an authentication mechanism on ICMP Redirects or Source-Quench,
>>>>>
>>>>>            
>>>> Which is why most networks block those packets from the outside.
>>>>
>>>>
>>>>          
>>>>> Nor is ARP authenticated.
>>>>>
>>>>>            
>>>> Which is why people control who can plug into their physical
>>>> network.
>>>>
>>>> None of the things you are saying support the idea of having
>>>> applications decide what the DSCP marking should be.
>>>>
>>>>          
>>> Does "decide what the DSCP marking should be" include complying to the recommendations of RFC-4594?
>>>
>>>        
>> If anyone cares, here's an update:
>>
>> I've submitted patches for QoS configuration for:
>>
>> APR/Apache (stalled);
>> Proftpd (committed);
>> Openssh (pending review);
>> Firefox/Thunderbird (reviewed and on-track for commit);
>> Cyrus (committed);
>> Sendmail (submittted and acknowledged, but not yet reviewed);
>> Curl (stalled);
>>
>> All, as per the request of the maintainers, default to either no QoS
>> markings or previous RFC-791 QoS markings if that's what they already
>> supported (Proftpd and Openssh).
>>
>> If anyone can think of anything else that needs to be supported to
>> impact a significant portion of network (or enterprise intranet)
>> traffic, please call it out.
>>      
> wget [1], like curl, is used for downloads of artifacts by some build systems.
>
> [1] http://www.gnu.org/software/wget/
>
>    

Ok, but I'm not sure that changes anything... what I was asking about 
was other services not enumerated: not how the above services are used.  
Sorry that wasn't clear.

-Philip

Re: Network QoS support in applications

[Rémi Denis-Courmont]

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

Re: Network QoS support in applications

[Henning Rogge]

[-- Attachment #1: Type: Text/Plain, Size: 1059 bytes --]

On Tue January 26 2010 13:56:50 Kalle Valo wrote:
> 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?
The IETF is discussing about a traffic priority below "best effort" for bulk 
traffic at the moment. Something you use to fill up links if your can but drop it 
if you are not sure. So it might be a good idea to make "best efford" not zero.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:henning.rogge-FCsFpRLaMoKatNDF+KUbs4QuADTiUCJX@public.gmane.org http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Network QoS support in applications

[Kalle Valo]

Henning Rogge <henning.rogge@fkie.fraunhofer.de> writes:

> On Tue January 26 2010 13:56:50 Kalle Valo wrote:
>> 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?
>
> The IETF is discussing about a traffic priority below "best effort"
> for bulk traffic at the moment. Something you use to fill up links
> if your can but drop it if you are not sure. So it might be a good
> idea to make "best efford" not zero.

I think 802.1d used zero for best effort to get it as the default. If
no class is set, the field will be zero and best effort is used.

-- 
Kalle Valo

Re: Network QoS support in applications

[Steven Blake]

On Tue, 26 Jan 2010 04:16:10 -0800 (PST), David Miller
<davem@davemloft.net>
wrote:

> From: Kalle Valo <kalle.valo@iki.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.

You are correct.  However, RFC 4594 is an attempt to get applications and
network operators on the same page.  There is no harm done if apps set DSCP
values in accordance with this RFC.

Regarding Bittorrent priority, see LEDBAT
http://www.ietf.org/dyn/wg/charter/ledbat-charter.html.


Regards,

// Steve

Re: Network QoS support in applications

[Kalle Valo]

Steven Blake <slblake@petri-meat.com> writes:

>> This is a local policy decision.
>> 
>> There is no universal way of doing any of this, really.
>
> You are correct.  However, RFC 4594 is an attempt to get applications and
> network operators on the same page.  There is no harm done if apps set DSCP
> values in accordance with this RFC.

Wow, this is great. Somehow I missed this, thank you very much. I will
read it in detail now. 

DiffServ people should have written something like this from the
beginning.

-- 
Kalle Valo

Re: Network QoS support in applications

[Olaf van der Spek]

On Tue, Jan 26, 2010 at 9:27 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> 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.

Maybe it shouldn't be done by applications, unless the streams of an
app use different priorities.
It might be useful to look at configuration of networked apps in a
broader sense, including stuff like to what IP addresses and ports an
app should bind. Maybe even to what Unix sockets or other transports.
Being able to configure this in one central place is way easier then
having to dive into the conf file of each individual application.
In this central place the QoS stuff could be configured too.

As this doesn't require application support, it's probably easier to
implement. It also provides more flexibility and maybe even more
security.

Olaf

Re: Network QoS support in applications

[Philip A. Prindeville]

Sorry for jumping in this late, after all, I did start this by stirring
up the whole issue... hate to be "hit and run".  ;-)

I'll try to catch up on the thread today, but here are a couple of
thoughts while I'm doing that.


On 01/26/2010 01:27 AM, 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.
>   

I would argue that application developers don't need to (and indeed
shouldn't) code QoS values into their programs.  QoS is a policy issue,
not a protocol one.

What I mean is that they should leave the configuration mechanism to
mark traffic, but let the site administrator (or more often, the site
network manager) decide on (and set) the QoS values to be used.

I've been working on this...  in most cases, the OSS package owners said
"put in the hooks", and have the default continue to do what's always
been done (even if (a) that means using TOS values [as opposed to QOS
values] that are obsolete, and (b) in some cases, the value of those
settings [i.e. IPTOS_LOWCOST] now conflict in a destructive way with new
meanings [that is ECN congestion settings])... and that's what has
typically been done.

There are, of course, no widely accepted standards for what mapping goes
with what application.  Some sites might consider video
mission-critical, others might consider it a bandwidth hog and a
nuisance that interferes with their transactional ODBC.

There is no one-size-fits-all.

So, going with the notional that the applications should be QoS-capable
but not out-of-the-box QoS-enabled, I've written the following patches:

https://support.ntp.org/bugs/show_bug.cgi?id=752

https://issues.apache.org/bugzilla/show_bug.cgi?id=42848

https://issues.apache.org/bugzilla/show_bug.cgi?id=48361

https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3184

http://proftp.cvs.sourceforge.net/viewvc/proftp/proftpd/contrib/mod_qos.c?view=log

ftp://ftp.redfish-solutions.com/pub/sendmail-8.14-qos.patch

https://bugzilla.mindrot.org/show_bug.cgi?id=1733


And I'm currently working on patches for Firefox and Thunderbird.

In the examples for the sample configuration files, when appropriate, I use the DSCP tagging values recommended in:

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html#wp1098122




> 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
>
> mac80211 uses these values to map the packets to DSCP classes. Most
> probably non other stack or driver (even non-wifi ones) use these
> values. Otherwise similar as Solution 1.
>
> 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
>     * using values over 256 is not intuitive 
>
> Solution 3: IPv4 DSCP field with values 0-7
>
> Most, if not all, wifi drivers should use it. And, in theory, the
> receiver should also benefit from the classification, unless ISPs
> modify it of course. But the standardisation for IPv4 QoS bits is a
> mess.
>
> Pros:
>
>     * visible in IP layer (but ISPs change the value often?) 
>
> Cons:
>
>     * applications need to handle IPv4 and IPv6 separately 
> ----------------------------------------------------------------------
>
>   

Solution 3': IPv4 with 1:1 mapping of Class-Selectors/Precedence to 802.1p

First, a lot of people hear "DSCP" and they freak out because it's
'complicated'.  Well, that's debatable, but let's not go there.

802.1p and Class-Selectors (i.e. the old RFC-791 meaning of
'precedence') are both fairly straightforward.  So let's go with that.

How about having a 1:1 mapping array that can be administrator specified
that maps class selectors (CS0-7) onto 802.1p precedence values?  We
could use sysctl -w to modify this locally.