From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> To: Kalle Valo <kalle.valo@iki.fi> Cc: Dunc <dunc@lemonia.org>, David Miller <davem@davemloft.net>, kaber@trash.net, netdev@vger.kernel.org, linux-wireless@vger.kernel.org Subject: Re: Network QoS support in applications Date: Tue, 26 Jan 2010 22:54:01 +0100 [thread overview] Message-ID: <20100126215401.GA25095@laped.iglesias.mooo.com> (raw) In-Reply-To: <87iqaplz5a.fsf@purkki.valot.fi> On Tue, Jan 26, 2010 at 04:27:29PM +0200, Kalle Valo wrote: > 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? > > 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
WARNING: multiple messages have this Message-ID (diff)
From: "Edgar E. Iglesias" <edgar.iglesias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org> Cc: Dunc <dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org>, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>, kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: Network QoS support in applications Date: Tue, 26 Jan 2010 22:54:01 +0100 [thread overview] Message-ID: <20100126215401.GA25095@laped.iglesias.mooo.com> (raw) In-Reply-To: <87iqaplz5a.fsf-ySPBbPOLdCfMApvqMRVM/A@public.gmane.org> 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
next prev parent reply other threads:[~2010-01-26 21:54 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 [this message] 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=20100126215401.GA25095@laped.iglesias.mooo.com \ --to=edgar.iglesias@gmail.com \ --cc=davem@davemloft.net \ --cc=dunc@lemonia.org \ --cc=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: linkBe 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.