From: "Philip A. Prindeville" <philipp_subx@redfish-solutions•com>
To: David Miller <davem@davemloft•net>
Cc: torsten.schmidt@s2006•tu-chemnitz.de, netdev@vger•kernel.org
Subject: Re: [PATCH] ipv4: add DiffServ priority based routing
Date: Thu, 11 Mar 2010 12:25:24 -0700 [thread overview]
Message-ID: <4B9943A4.8040606@redfish-solutions.com> (raw)
In-Reply-To: <20100112.130355.144803575.davem@davemloft.net>
On 01/12/2010 02:03 PM, David Miller wrote:
> From: "Philip A. Prindeville" <philipp_subx@redfish-solutions•com>
> Date: Tue, 12 Jan 2010 12:59:36 -0800
>
>> What has changed is how network equipment is required to interpret
>> the meaning of those bits.
>>
>> Even if we pass the bits "as is" to the network, if the network is
>> applying entirely new semantics (and when I say "entirely new", I
>> mean those mandated since 1998), then compatibility in the host
>> kernel API doesn't matter a hoot since the packets will still be
>> handled by every transited router according to the modern semantics.
>
> People really don't assign global meaning to bits set by applications
> in the TOS field.
>
> What they do is they have a set of semantics inside of their cloud of
> routers and switch points for diffserv, and when packets come in the
> TOS field is rewritten to whatever scheme is being used inside of that
> cloud.
>
> And the diffserv bits only have meaning and effect within that cloud.
>
> So really, having a syscall that sets the TOS bits exactly by
> applications is just fine.
>
> People are doing diffserv right now with Linux and have done so
> for years.
Sorry about coming back to this weeks later... but I hadn't seen RFC 4594 previously.
What if boxes (i.e. the OS) and applications can preconfigured to use RFC-4594 guidelines by default, and varying from that required the administrator to make specific changes?
I agree with the notion that certain values should be set side-wide (or at least system-wide) to prevent malicious users from exploiting QoS... that's why I've been advocating for QoS settings to be specified in a system configuration file, and not a per-user configuration file.
-Philip
next prev parent reply other threads:[~2010-03-11 19:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 13:32 [PATCH] ipv4: add DiffServ priority based routing Torsten Schmidt
2010-01-12 20:16 ` David Miller
2010-01-12 20:59 ` Philip A. Prindeville
2010-01-12 21:03 ` David Miller
2010-01-12 21:33 ` Philip A. Prindeville
2010-01-13 4:47 ` Steven Blake
2010-03-11 19:25 ` Philip A. Prindeville [this message]
2010-03-11 19:29 ` David Miller
2010-03-11 19:32 ` Philip A. Prindeville
2010-03-12 11:18 ` Benny Amorsen
2011-02-21 6:01 ` Philip Prindeville
2010-01-14 11:50 ` Torsten Schmidt
2010-01-14 12:50 ` Eric Dumazet
2010-01-15 0:51 ` David Miller
2010-01-15 8:24 ` Eric Dumazet
2010-01-15 8:26 ` David Miller
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=4B9943A4.8040606@redfish-solutions.com \
--to=philipp_subx@redfish-solutions$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=torsten.schmidt@s2006$(echo .)tu-chemnitz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox