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

"Fred Baker (fred)" <> Mon, 29 April 2013 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDB4D21F98E4 for <>; Mon, 29 Apr 2013 16:36:30 -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 99OmuMxICmnW for <>; Mon, 29 Apr 2013 16:36:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF7D321F9698 for <>; Mon, 29 Apr 2013 16:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2313; q=dns/txt; s=iport; t=1367278580; x=1368488180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5rjeI4zUBl3fK34y8Pnyeb0riUDztuOL/P1WxUjLLxQ=; b=jY+cY324wUkUc4YSbEEn0a8ZSr2ll7xB+AmiYttX3wakiga/Z9To8BF1 3XeHN28U7UUVp80DKcmGpql0UqLWbyR0ozC4q88d1JP3Q4f5xwWVZeL+x NH0JawNF1jm5kJ1FKaz8/E8igjIwe1pl+q2RNscxIUZzRxEf3oLl0/hvz s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,576,1363132800"; d="scan'208";a="204479650"
Received: from ([]) by with ESMTP; 29 Apr 2013 23:36:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r3TNaJW6030521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 23:36:19 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 18:36:19 -0500
From: "Fred Baker (fred)" <>
To: Linda Dunbar <>
Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #2
Thread-Index: AQHORTJZMUuz8EMmv0mvp1xSBdVe0w==
Date: Mon, 29 Apr 2013 23:36:18 +0000
Message-ID: <>
References: <> <> <20130429215002.GB23227@verdi> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: John Leslie <>, "" <>
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: Mon, 29 Apr 2013 23:36:30 -0000

On Apr 29, 2013, at 3:28 PM, Linda Dunbar <> wrote:

>>   I don't follow your point here. There are cases where ECN marking
>> may not work very well, but I don't see any correlation to the size
>> of the network. (ECN signals reach a receiving endpoint unless
>> something
>> is broken.)
> [Linda] Congestion can be transient.

>From my perspective, network congestion is almost always transient; non-transient congestion is an outage or should be. Operators tend to measure on time scales of 300 ms, for reasons related to the tool (MRTG) commonly used to measure it. But congestion on the time scale of a TCP session is measured in RTTs, which are on the order of milliseconds to hundreds of milliseconds.

The direction you are arguing suggests that there is no value in TCP Congestion Control, for the simple reason that in the next RTT a given TCP may have nothing more to send. I hope that's not what you mean, because that doesn't square very well with measurable reality. It is true that sessions are predominantly short, and short sessions add a lot of noise to any measurement. However, the actual traffic is predominantly from longer sessions, and absent congestion control in one form or another would drive the network into congestive collapse.

If you believe that there is value in congestion control, the question on the table is whether there is value in explicit vs implicit signaling.

> For a network with many hops, the congestion might not exist anymore by the time the Source nodes receive the notification from the end points. 
> When many source nodes throttle back traffic (or control ingress rate) for transient congestion, network oscillation can occur, which is not good. 

Hops are irrelevant, in my view. What is relevant is the duration of sessions and of RTTs. I can show you the same behavior in many-hop and few-hop networks.

> Network can perform much better if there are two different types of congestion marking, one for transient congestion, and another one for congestion caused by "hard degradation" (e.g. LAG link member failure, or microwave link bandwidth being reduced due to weather, etc). 

That might be ECN and loss?