Re: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada

"Flohr, Julius" <julius.flohr@uni-due.de> Wed, 19 July 2017 11:19 UTC

Return-Path: <julius.flohr@uni-due.de>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C22131CA0; Wed, 19 Jul 2017 04:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4Pqd5VLD_Bh; Wed, 19 Jul 2017 04:19:33 -0700 (PDT)
Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8393612EBFA; Wed, 19 Jul 2017 04:19:33 -0700 (PDT)
Received: from HT02.win.uni-due.de ([132.252.185.215]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id v6JBJPAp010213 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 19 Jul 2017 13:19:25 +0200
Received: from ccr01.win.uni-due.de ([169.254.1.129]) by HT02.win.uni-due.de ([132.252.190.234]) with mapi id 14.03.0319.002; Wed, 19 Jul 2017 13:19:25 +0200
From: "Flohr, Julius" <julius.flohr@uni-due.de>
To: Sergio Mena <semena@cisco.com>
CC: Anna Brunstrom <anna.brunstrom@kau.se>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "rmcat@ietf.org" <rmcat@ietf.org>, "draft-ietf-rmcat-nada@ietf.org" <draft-ietf-rmcat-nada@ietf.org>
Thread-Topic: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada
Thread-Index: AQHS8Y2q2hRvF1kBTEi6t1oeGcWbZ6JDcuQAgBXQpgCAAN9/AIAAkgQAgABID4A=
Date: Wed, 19 Jul 2017 11:19:24 +0000
Message-ID: <830396B0-DCDB-42F3-BAF7-EE122CA123D1@uni-due.de>
References: <7c5453a5-65f6-6f74-6214-346469c8abce@kau.se> <c8d9ec64-c332-fa8d-dd20-3dd307aabb97@kau.se> <DB4PR07MB348F7D8702DC16028081554C2D70@DB4PR07MB348.eurprd07.prod.outlook.com> <62513FF8-0A36-45FC-878C-7D03A1772A2A@uni-due.de> <6ca96a44-0ca2-2704-41f6-3eaeaf35afa7@kau.se> <aa200a17-1d8c-9570-2b51-364a08a131a6@cisco.com>
In-Reply-To: <aa200a17-1d8c-9570-2b51-364a08a131a6@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [132.252.190.221]
Content-Type: text/plain; charset="utf-8"
Content-ID: <727D1058CB41E5448985D2823CC5943C@win.uni-due.de>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/6knAFbMyE0jNoD-lKSKXz9LjONA>
Subject: Re: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 11:19:36 -0000

Hi,

> On 19. Jul 2017, at 09:01, Sergio Mena <semena@cisco.com>; wrote:
> 
> 
> As for Julius's tests, we thank Julius for the effort put into it, and would like to see how his results compare to our latest ones (see Slides presented by Xiaoqing in April's RMCAT interim).
> 

I haven’t done too much testing, but as far as I can tell there is an issue when the bottleneck bandwidth is smaller than RMAX: 
If you have a competition scenario between NADA and a loss based flow, it seems that nada gets stuck in the competitive mode because itself creates queueing delay that is larger than QTH. 

I actually made a little mistake when I said the problem has gotten worse compared to the last version of the draft. The issue actually has been introduced in version 03 with the introduction of TEXPLOSS. Before, the draft was very unclear and stated that one should warp the congestion signal IFF packet loss is present, but without stating a time span.

Therefore the implementation just used the knowledge it had from the recent observation window LOGWIN (500 ms). That worked really well because it helped the algorithm to return to the normal mode of operation more easily, because after that timespan it would stop warping regardless whether there is lots of queueing delay present or not.

I don’t know if this is an issue with my implementation or if there is an actual issue with the algorithm, but this is what I have observed.

I’ll contact Xiaoqing and Sergio directly so we can work together on this issue and post our findings to this mailing list directly.

Regards,

Julius


=====================================
Julius Flohr, M.Sc.
University of Duisburg-Essen
Computer Networking Technology Group

Room SL-408
Schützenbahn 70
D-45326 Essen/Germany

E-Mail:  julius.flohr@uni-due.de
Phone: +49-201-183-7667
Fax:     +49-201-183-7673
=====================================