From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 79C183CB45 for ; Fri, 23 Nov 2018 21:59:39 -0500 (EST) Received: by mail-lj1-x235.google.com with SMTP id g11-v6so12093505ljk.3 for ; Fri, 23 Nov 2018 18:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UHm7/UP9hzKIGhdt2bmmBQKf4ZJ9zhw8hv0t3p3ujXQ=; b=DeVKCc1N++I5s4I866F8Joari0oxS9/u4D3LY/O3QlIB0U8fCWkcOImcnB9lB6gFoT T2ubK67RtaQkx82oD5862VvEHUhEyXoIxCPomBF4HfU1qfBrVar2iHIzGje3K+k0sSHQ 4JnufbEvMP1lDEWn1XIyeuER6B2AoOehFNSvCHEyatXvVkXyiL/1+ez7/njkdFielv1y gzoFiKJD8SvNdNl1lcg3KAGW9NEbTpApZkof4EYOiljESj6YASn9ymviZa9u09+cNRfc mQAUmxTZSwDQeQxWDviJiBfEXoTQwawuHJmSIlyDupViurYr3vS4Zw6yXtKJRL5mJVd8 I0uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UHm7/UP9hzKIGhdt2bmmBQKf4ZJ9zhw8hv0t3p3ujXQ=; b=CyNlvOlsC7DurVrEjFkIoig2Czrl3sf9xkZXdhjfUnTrc+EdeTvY+bMp05gGt7JLKq km5pWibB4txQ0UErMoSR2B3ONB7tIg3NjdZyOLleE/fscsPzzq1w3b/6cgVZai+PUjXx UQIvx6y0QY/O6D5OX1mi0XBO3BNEcPoBKkLUmN+pxEHCz6yu5R9d/1y9RgP7rk+Uj5s1 zt8oo3qeNsqG9MYDxa+4EztPzPFoMLLhKbnJnounACb3lij8Oe13Y+T7bRCyTIOuesPK zsbSV0boYfV5Kqw15MAfcP8pLNsYi07w8/CeW8geNfpIA4/IURUJTZjZ7U7ro1k5WeUl 1kIQ== X-Gm-Message-State: AA+aEWaJ8r7JgT8GxGDwXmxTUzmrtQOThRRxFG7ou+l1Ao+5Ojojn779 aWMOZRK9CFbinA7lgw/9wnc= X-Google-Smtp-Source: AFSGD/VXLWEyQ1O34XcTxYNxkvWVeSjOYJpzuV0UrSs6NpMI70UWddNS/iYtOi/BctTL+k18DiVz0g== X-Received: by 2002:a2e:9715:: with SMTP id r21-v6mr2026542lji.30.1543028378001; Fri, 23 Nov 2018 18:59:38 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-236-220-nat-p.elisa-mobile.fi. [83.245.236.220]) by smtp.gmail.com with ESMTPSA id 11-v6sm4397862ljv.1.2018.11.23.18.59.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Nov 2018 18:59:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Sat, 24 Nov 2018 04:59:35 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Cake List , Jendaipou Palmei Content-Transfer-Encoding: quoted-printable Message-Id: <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> References: <87va4nzsn4.fsf@taht.net> To: Dave Taht X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 02:59:39 -0000 >> This is possibly a correct result in your simulation!! - the periodic >> throughput drop you are showing in cobalt at this bandwidth and rtt. >> I'm happy to see cobalt kick in early on slow start but not happy to >> see the periodic drop. Jon, do you have time for a code review? >=20 > I looked at it briefly, but the code structure is different enough = that I need to sit down and study it carefully to figure out whether = there are any relevant differences. >=20 > The throughput drops most likely occur because the TCPs become = synchronised and remain so under AQM action. You can see that the = frequency of the system is lower in the later part of the COBALT run = than in the Codel run, but the same as Codel in the earlier part where = throughput drops don't occur. But this shouldn't really occur with a = Codel-based AQM (as COBALT is), because a single mark is sufficient to = tell TCP to back off over one RTT. An explanation might be if this = implementation of COBALT isn't running down correctly when deactivated, = so the mark frequency only rises while being turned on and off. The = run-down behaviour is a major intentional difference between COBALT and = reference Codel. >=20 > I'll look at the code more closely with that in mind. Okay, I've had a look - not quite line by line, but the parts I consider = important for the behaviour seen so far. There are a couple of small behavioural differences between your code = and mine, which should be corrected if the model is to accurately = reflect the prototype. These are probably not relevant for the results = shown so far, but are likely show up on more aggressive tests involving = unresponsive traffic. - On queue overflow, a tail drop is used to resolve it. While not = technically part of COBALT, Cake performs head-dropping on queue = overflow, doing so from the longest queue, and I consider that to be = best practice. This gets the message to the offending sender ASAP, = without having to bubble up through the jammed queue first. If the = packets currently at the head of the queue are smaller than the one = being offered, you might need to drop more than one to maintain the size = invariant. - The hard-drop flag for BLUE is set at the top of the control-law = function, and tested in order to bypass the Codel logic if already set. = This is not how the COBALT code operates; the BLUE logic should come = last, and the Codel logic run unconditionally. Everything else looks reasonably correct at first glance (though the = amount of boilerplate is epic). I would recommend verifying that = CobaltQueueEmpty() actually gets called when appropriate though. = Without it, I suspect that the run-down logic won't work as intended. - Jonathan Morton