Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2

"Fred Baker (fred)" <> Tue, 30 April 2013 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 677ED21F9BC5 for <>; Tue, 30 Apr 2013 10:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.372
X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IjdQ6bEBIZzA for <>; Tue, 30 Apr 2013 10:05:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 784ED21F9BB5 for <>; Tue, 30 Apr 2013 10:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3514; q=dns/txt; s=iport; t=1367341541; x=1368551141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=71NpOJ/+KP7Tg6dlQj3wtPIOPaBT4pr7fhW9Y+lCBQA=; b=cmPA3QCE5xyciWVHktI4GuB2elMQCzfEaQT/3sf2IzoC/aSwYzqPi5MY oTOvEeDApWtY25LZWB5aSF8H2ghS4FwJuUs0jzTNqiozLO0Lgs4+/eKP5 7DImj4282kcZzeFgW1ZmM5frJ5kF06J9Nm4OkoxU2IZbBErmwS8MKgSst Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAHP5f1GtJXG9/2dsb2JhbABSgwc2vlx+FnSCHwEBAQMBbAoDBQsCAQgOCgokMiUCBA4FCId+BgyxVY5ajmYCMQeCb2EDiF2KeoR1kAeDDYIn
X-IronPort-AV: E=Sophos;i="4.87,582,1363132800"; d="scan'208";a="204867672"
Received: from ([]) by with ESMTP; 30 Apr 2013 17:05:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r3UH5eie010410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Apr 2013 17:05:40 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 12:05:40 -0500
From: "Fred Baker (fred)" <>
To: Wesley Eddy <>
Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #2
Thread-Index: AQHORcTx5E7/RQSTmEyrnXRCxUSVUg==
Date: Tue, 30 Apr 2013 17:05:40 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Apr 2013 17:05:46 -0000

On Apr 30, 2013, at 9:29 AM, Wesley Eddy <>

> On 4/29/2013 10:00 AM, Fred Baker (fred) wrote:
>> Do we generally agree with the recommendation of This is the question of signaling to an endpoint using both dropping and ECN.
> I think there are two recommendations embedded at the end of the
> section:
> """
>   Hence, network communication to the host regarding the moderation of
>   its traffic flow SHOULD use an AQM algorithm to determine which
>   packets it should affect, and then implement that effect by marking
>   ECN-capable traffic "Congestion Experienced (CE)" or dropping non-
>   ECN-capable traffic.
>   Due to the possibility of abuse, the queue must also impose an upper
>   bound, so that even ECN-capable traffic experiences tail-drop if
>   necessary; this possibility, while equipment must design for the end
>   case, should in theory be very uncommon.
> """
> I'm basically good with both.
> The second part (imposing an upper bound) might be worth expanding a
> bit.  I don't know what a reasonable upper bound is, for failing into
> a tail-drop mode, and it smells like another knob to be configured,
> which we are hoping to avoid :).
> So, there is a can of worms here.  Should the threshold be configurable?
> Should it be based on some margin computed from the queue depth, link
> rate, etc?  What should the defaults be?  What types of experiments
> would we do in order to test sensitivity of this parameter and tune it?
> I think all of these depend a bit on how the specific AQM works, and
> it's tough to say much concrete about it.
> -- 
> Wes Eddy
> MTI Systems

Hmm. Maybe I should separate them into separate recommendations.

Yes, I think ECN has the built-in possibility of an end system using the flag to gain what it thinks is some variation on preference - it can get one more packet into a queue than it would if it didn't advertise an ECN capability, but it doesn't actually implement RFC 3168 etc. At some point, one has to drop even ECN-capable traffic. Not for AQM reasons; for defensive reasons.

I have, and dare I say "we have", observed several implementations that have tried the approach of bending the rules to gain preference. BitTorrent did so by having multiple parallel aggressive TCP-like connections; we all know the outcome of that - multiple connections is fine, but bulldozing networks is a good way to get yourself bulldozed. One TCP implementation I know of did away with slow start and congestion control altogether. Guess what happened; a repeat of the 56 KBPS NSFNET in a more confined environment. If such implementations become at all widespread, and that one did within the company that wrote it, it gets to compete with itself, and it's not a pretty sight. There are other ways to deal with that kind of thing than "we who are wise thumb our collective noses in your general direction". In the end, money talks, and customers prefer networks that work and transport implementations that work in those networks.

I personally don't have a problem with the *ability* to configure something; where I think we have issues is the *necessity*. On your other questions, I might refer you to the sixth recommendation; if we don't have papers that tell us that, let's write some.