From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rick.jones2@hp.com>
Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "smtp.hp.com",
	Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK))
	by huchra.bufferbloat.net (Postfix) with ESMTPS id 77A6D201A91
	for <codel@lists.bufferbloat.net>; Mon,  7 May 2012 19:16:27 -0700 (PDT)
Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44])
	by g1t0029.austin.hp.com (Postfix) with ESMTP id 1A06938158;
	Tue,  8 May 2012 02:16:26 +0000 (UTC)
Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213])
	by g1t0038.austin.hp.com (Postfix) with ESMTP id ADBB330481;
	Tue,  8 May 2012 02:16:15 +0000 (UTC)
Message-ID: <4FA881F6.9080808@hp.com>
Date: Mon, 07 May 2012 19:16:22 -0700
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jim Gettys <jg@freedesktop.org>
References: <1336246349-20228-1-git-send-email-dave.taht@bufferbloat.net>
	<4FA7FBC7.2040501@hp.com>
	<1336410626.3752.2329.camel@edumazet-glaptop>
	<4FA805F9.20004@hp.com>
	<1336412079.3752.2333.camel@edumazet-glaptop>
	<CAA93jw60g4Jt6RkvS9cEL1x+_7bRSQ547cJ3ObSx-2tBCjXw=A@mail.gmail.com>
	<4FA81549.5060609@freedesktop.org>
	<CAA93jw6ZbMuFyK5ct+Nrj2Uzb-TpUjvwSGmzG+hHi=yasn_b+A@mail.gmail.com>
	<4FA8197C.4090909@freedesktop.org>
	<1336418211.3752.2353.camel@edumazet-glaptop>
	<4FA82422.9040500@freedesktop.org>
	<1336421020.3752.2359.camel@edumazet-glaptop>
	<4FA873A0.40803@freedesktop.org>
	<A89B0AB0-38A7-4FA8-88B8-83F06CAF5056@gmail.com>
	<4FA87ABC.4080907@freedesktop.org>
In-Reply-To: <4FA87ABC.4080907@freedesktop.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Eric Dumazet <edumazet@google.com>, Dave Taht <dave.taht@bufferbloat.net>,
	codel@lists.bufferbloat.net
Subject: Re: [Codel] [PATCH 1/2] codel: Controlled Delay AQM
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/private/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2012 02:16:27 -0000

On 05/07/2012 06:45 PM, Jim Gettys wrote:
> On 05/07/2012 09:20 PM, Andrew McGregor wrote:
>> Sure... but making the Linux codel ECN capable, and even on by
>> default with no configuration, will have no effect if the clients
>> don't use ECN.  So there's no need to even make it optional, let
>> alone default to off.
>>
>>
> The problem is that the client may be managing it's outbound queue with
> codel.  So you have to negotiate ECN and if you start marking, you may
> run into trouble.

Are the odds really all that high that when the admin of the client set 
tcp_ecn = 1 (or its non-Linux equivalent) that codel running on his 
system would be the only thing actually marking and so "the" reason for 
trouble?  I'm inclined to agree with Andrew.  If the client is going to 
have trouble with ECN, it will have it once it sets tcp_ecn = 1, codel 
being there or not.

rick