[aqm] Congestion levels (draft-ietf-aqm-eval-guidelines-02.pdf)

Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> Sun, 29 March 2015 09:16 UTC

Return-Path: <Szilveszter.Nadas@ericsson.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0F4101A0222 for <aqm@ietfa.amsl.com>; Sun, 29 Mar 2015 02:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8gujmFGpG_IA for <aqm@ietfa.amsl.com>; Sun, 29 Mar 2015 02:16:51 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0261A0271 for <aqm@ietf.org>; Sun, 29 Mar 2015 02:16:50 -0700 (PDT)
X-AuditID: c1b4fb30-f79996d000006ebb-11-5517c3000681
Received: from ESESSHC016.ericsson.se (Unknown_Domain []) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.43.28347.003C7155; Sun, 29 Mar 2015 11:16:48 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([]) by ESESSHC016.ericsson.se ([]) with mapi id 14.03.0210.002; Sun, 29 Mar 2015 11:16:48 +0200
From: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>
To: "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: Congestion levels (draft-ietf-aqm-eval-guidelines-02.pdf)
Thread-Index: AdBpsGXaYwmD6/3XQ1+0O9uINDh+tQ==
Date: Sun, 29 Mar 2015 09:16:47 +0000
Message-ID: <EA4C43BE752A194597B002779DF69BAE23CC4540@ESESSMB303.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23CC4540ESESSMB303erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvjS7DYfFQg23PjSzW7JN0YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGidsvmQt+tTFWPGt5wdTAuKaZsYuRk0NCwERi14mfbBC2mMSF e+uBbC4OIYGjjBL/ehcxQzhLGCXudS9hBqliE7CQaFi5GaxDREBRYsuv+2BxYQEnibuH3zJB xN0lmtb2skPYehL3fu0Hs1kEVCXOTp8FtplXwFfi0s3HYL2MQJu/n1oD1sssIC5x68l8JoiL BCSW7DnPDGGLSrx8/I8VwlaSaFzyhBWiPl+i8cd1JoiZghInZz5hmcAoNAvJqFlIymYhKZvF yAEU15RYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJL NjECo+Lglt8GOxhfPnc8xCjAwajEw/tginioEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYe71ZDm48+OBQOss0Lt/z8893PZWZopG10bBJ8MnSGVsnbSzf /9e3Qzhy09QT77ZumOnNo2zfY3slI+322hv/BeOZnZMnTqzdcTu0USKPy2o6S6QP64o15j7T ix6//L58yqbvO6bxuc09+lkrT2rOX6WVfKEbfzfOZd2VfEtM2E9l/qfajBVSEkosxRmJhlrM RcWJAKpMjs1rAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/b3GTJG111eqw30spytqGyd-cJyc>
Subject: [aqm] Congestion levels (draft-ietf-aqm-eval-guidelines-02.pdf)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2015 09:16:55 -0000


To clarify my comments at the mic somewhat. I do prefer this definition compared to the previous version reviewed at Hawaii. I am not quite sure when it comes compared to the definition Mirja said, there are different pros and cons of the two definitions.

I think there is a considerable complexity of this definition as Mirja also said. I see it less confusing and I think that drop tail queue might a good enough reference. Still there are issues with this, e.g. several packets of the same flow lost in an RTT. Also the actual percentages are hard to find, some simulations/calculations would be maybe useful to back up the actual numbers used.

A thing which occurred to me is that while these numbers are independent of the AQM being used, they are not independent of the buffer size used. Optimal/desirable buffer sizes (both in ms and octet) might be significantly different for different bitrates and RTTs, and it might be hard to actually compare the algorithms if they use different buffer sizes. Maybe a recommendation for reference buffer size would be a good addition to make comparisons more correct.

Bitrate based definition (i.e. what bitrate a single flow can achieve if that flow experiences its fair share) might be better from simplicity point of view, but they somehow do not feel quite right for me (I know that this is not a very strong argument:) ).

On why do I think it is important to have congestion level definition. It is because high congestion is when an AQM is stressed the most, however improvements for high congestion must not result in performance degradation for lower levels.

I leave it to the authors’ consideration whether to include any of this in an update.


From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Scheffenegger, Richard
Sent: Friday, March 27, 2015 10:05
To: aqm@ietf.org<mailto:aqm@ietf.org>
Subject: [aqm] IETF92 meeting minutes

Hi AQM’ers,

The Meeting Minutes for IETF92 have been compiled. Thanks to Anna Brunstrom for taking very good notes, and other participants to already provide additions.

If you have made a comment on the microphone, please review the minutes and check if the essence of your comment have been captured.


Also I’d like to thank again for all those who have committed to review the various documents, as listed at the beginning of the minutes.

Best regards,
  Richard Scheffenegger