netdev - Re: [PATCH] ipv4: add DiffServ priority based routing

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Jan 2010 12:59:36 -0800
From:	"Philip A. Prindeville" <philipp_subx@...fish-solutions.com>
To:	David Miller <davem@...emloft.net>
CC:	torsten.schmidt@...06.tu-chemnitz.de, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: add DiffServ priority based routing

On 01/12/2010 12:16 PM, David Miller wrote:
> 
> You can't do any of these things you are doing, I've basically been
> ignoring all of these crazy diffserv patches, they're nuts!
> 
> The TOS socket option has a meaning and behavior defined by the BSD
> sockets interface many years ago.  And you cannot and must not change
> the behavior of those system calls because applications are written to
> the current behavior and you will break them.  Protecting the new
> behavior with a kernel config option is a non-starter, it's pointless
> because no distribution is going to enable a kernel option that
> knowingly breaks applications.
> 
> And it is also possible to set the TOS field however you desire using
> what the kernel currently provides, we do not preclude proper diffserv
> support, the BSD socket interfaces allow that just fine.
> 
> And you can also do diffserv by classifying traffic and setting the
> TOS field using either the packet scheduler, or even netfilter.
> 
> Linux supports diffserv fully and just fine, you just can't see it :-)
> 
> Please stop submitting these patches without first having at least a
> real discussion and understanding of how this stuff works.
> 
> Thanks.

I disagree.

The TOS socket option means "use these bits as the value of iphdr->ip_tos exactly as I'm giving them to you".

That hasn't changed.

What has changed is how network equipment is required to interpret the meaning of those bits.

As for "And you cannot and must not change the behavior of those system calls because applications are written to the current behavior and you will break them."  For me, this is the real non-starter.  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.

I note that the lower two bits of the TOS field were appropriated for ECN at the same time, and that hasn't broken a thing.

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