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

"Scheffenegger, Richard" <> Fri, 10 May 2013 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BA1421F8EAA for <>; Fri, 10 May 2013 05:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.371
X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fDX799C8NbZg for <>; Fri, 10 May 2013 05:53:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95B0D21F8E51 for <>; Fri, 10 May 2013 05:52:58 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.87,647,1363158000"; d="scan'208,217"; a="257481793"
Received: from ([]) by with ESMTP; 10 May 2013 05:52:59 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4ACqwWA009396; Fri, 10 May 2013 05:52:58 -0700 (PDT)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 10 May 2013 05:52:58 -0700
From: "Scheffenegger, Richard" <>
To: Vijay Subramanian <>, "Fred Baker (fred)" <>
Thread-Topic: [aqm] Question re draft-baker-aqm-recommendations recomendation #5
Thread-Index: AQHOTONoFLlfr73IdE2qxO+qQN84sZj+XcSA
Date: Fri, 10 May 2013 12:52:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: de-AT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F24B77239SACEXCMBX02PRDh_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5
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: Fri, 10 May 2013 12:53:10 -0000

Hi Fred,

I agree with Vijay and Michael;

The last four words of the title can also be confusing [to the session, other flows, ...] (without incurring loss or undue round trip delay).

If such a section remains, I'd argue against naming of specific protocols; from a router / AQM POV, it might be worthwhile to mention what an AQM SHOULD NOT do considering common congestion control algorithms (ie. delay the congestion signal - obviously; drop  entire flights or lots of consecutive packets of one flow - difficult without state; drop/mark retransmitted packets  - again difficult without a means to identify them. RFC3168 for TCP (SCTP) recommends, however, that retransmissions should not be ECT marked. However I am dubious about the claimed benefit; a lost (as the only means to signal persistent congestion) retransmitted segment is WORSE than a lost original packet (which carries ECT, and would only receive a CE mark). Also, Linux seems to ignore that specific paragraph in RFC3168...).

So, without focusing only on TCP CC - are there any scenarios where an AQM could overshoot and elicit too much of a reaction from a transport CC [dropping a retransmitted segment will cause a RTO with IETF spec'd TCP/SCTP]? If they are general (ie. applicable to SCTP, DDCP, [RTMFP]...), documenting them in this document seems reasonable.

Best regards,

Richard Scheffenegger

From: [] On Behalf Of Vijay Subramanian
Sent: Donnerstag, 09. Mai 2013 20:31
To: Fred Baker (fred)
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5

Hi Fred,

A couple of points.
1: The recommendation mentions TCP and SCTP but not transports such as DCCP. I assume the recommendation holds for all transports.
2: The focus of this draft seems to be on AQMs and the other recommendations seem to deal with actions that routers can take. I am not sure what action
 on the part of a router is being recommended here. If this goal can be achieved using ECN, it is already covered in recommendation #2.


On 9 May 2013 07:00, Fred Baker (fred) <<>> wrote:
Do we generally agree with the recommendation of This is the question of TCP/SCTP Congestion Control: I would like to, as a community, recommend that it maximize throughput while minimizing delay, which is to say, do so without being overly aggressive.

aqm mailing list<>