netdev - Re: DSCP values in TCP handshake

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]

Message-ID: <BANLkTi=fDdoF=kSfY=9ER4iR3M27L=CLXw@mail.gmail.com>
Date:	Tue, 19 Apr 2011 11:09:41 -0400
From:	Matt Mathis <mattmathis@...gle.com>
To:	Mikael Abrahamsson <swmike@....pp.se>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	Joe Buehler <aspam@....net>,
	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: DSCP values in TCP handshake

> I don't know why this didn't make it into RFC, I can inquiry if there is
> interest.

Please do.    This missing spec is one of the things that makes Less
than Best Effort (aka scavenger service) unusable.   Only the client
knows if they are fetching data in the background.   The server
doesn't care.

The other botch it is the spec that DSCP can be cleared under certain
conditions, which has the effect of promoting LBE to BE.   I have lost
track of the details.

Making LBE work would go a long way to solving the buffer bloat
problem and more....

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay




On Tue, Apr 19, 2011 at 12:28 AM, Mikael Abrahamsson <swmike@....pp.se> wrote:
> On Mon, 18 Apr 2011, Stephen Hemminger wrote:
>
>> Linux does not look at DSCP of incoming packets (there is no queue).
>
> Then I see no reason for the policy of not reflecting DSCP.
>
> If we receive the DSCP marked packet then it means the network is either not
> QoS enabled (it doesn't care) or it's actually allowed through the border
> router with DSCP unchanged. Either means it's safe to reflect the DSCP
> value, either it will have no effect or it's actually meant to be
> prioritized.
>
> With precedence, it originally was mandated that if the precedence value
> changed, the TCP session should be reset. Fortunately, this was changed but
> I would still say that it's thought that DSCP values should be reflected by
> the server.
>
> For instance:
>
> <http://tools.ietf.org/html/draft-ietf-ieprep-reflexive-dscp-02>
>
> "The requester could initiate this. Thus, if the DSCP
>   received on one TCP segment differs from the TCP used on a prior TCP
>   segment in a session, the new DSCP SHOULD be reflected unless local
>   policy prevents this."
>
> I don't know why this didn't make it into RFC, I can inquiry if there is
> interest.
>
> --
> Mikael Abrahamsson    email: swmike@....pp.se
> --
> 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
>
--
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