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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1104191934270.13186@uplift.swm.pp.se>
Date:	Tue, 19 Apr 2011 19:38:44 +0200 (CEST)
From:	Mikael Abrahamsson <swmike@....pp.se>
To:	Matt Mathis <mattmathis@...gle.com>
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

On Tue, 19 Apr 2011, Matt Mathis wrote:

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

I emailed with Fred Baker and the below text seems to be where it ended 
regarding reflexive marking of packets. If someone wants this changed, 
they need to bring it up with the IETF.

<http://www.ietf.org/proceedings/54/220.htm>

"Fred Baker presented draft-ietf-ieprep-packet-marking-policy-00.txt

Van Jacobsen presented a concern for Kathy Nichols, Diffserv co-chair. The 
concern was that the DSCP is intended to identify traffic supported by a 
service, as opposed to traffic of a certain application type. He also 
worried that a specific BCP indicating the facilities used to support such 
services might be misused by regulators to mandate ISP services. 
Specifically, he wanted a statement between the requirements document and 
a document suggesting a specific configuration identifying the fact that 
inter-service-provider signaling as specified in this draft is certainly 
specified but is not commonly implemented.

Christian Huitema and another speaker also commented that while a cookbook 
such as this was an interesting useful document, it didn't seem to 
directly stem from emergency as a context.

Rei Atarashi presented draft-ietf-ieprep-reflexive-dscp-00.txt

Van basically felt that the notion of a default response from the host was 
inappropriate; this is something every network should provide a policy 
for. "

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