From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 6DEFF3B29E for ; Tue, 28 Nov 2017 11:16:45 -0500 (EST) Received: by mail-qk0-x22c.google.com with SMTP id b184so446007qkc.13 for ; Tue, 28 Nov 2017 08:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VAjlm94OJZMem8RW4WZRJUs14Ou/obJoPN7dqPLVE1I=; b=nMwjdZgLFwDEewR8PQvKYBomAeBcKcrMC68fFJl5UmyrfWxOY1f35ROc7d6krhK7Gz DCf7qMS9rEBQqGGwpiWXZX+xKR2HfJda32zTBNquXgv4dLr57rgdgMnDXQgmTC4T7159 7Ak6a23ix0FIROFH7H3jSIKpola1xvZlUb/h8DqyLFbTZf87/gQJ314NgvbYrlxQ1f0u LJSOrfUKegA1LY/Nd/UOXN/Fmh5tE4j2iKQkT2TGeOvVmNeG1qJVm4SV248n2p+4nes7 wsodkz3Nbt71kWH1XBmpNt/efDMgpparxwXXlXKA3WLkfgAMbDrpgfNMm3SAiZLBwKPI /r6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VAjlm94OJZMem8RW4WZRJUs14Ou/obJoPN7dqPLVE1I=; b=mEZg8Gz9JPcp1YBam7dcTRjOIocrlqFuPFv5bpzKKhZqM6eW38JeoTaCUJVm4Wtt+h ktjROXqPLoHlti8v7cwBkETD+YETymbvw87Z46HzK8Dz7e2YNT3fV3QEEKecnT0YagQV /l+h9+Rr5qR8dcyWoIcDT0iUP6FlpKXX/DOWXRVUxH6/Zqb9ebY4J7iy2f1wjREXwaW+ pXQHUqqd98wFvpyg/u9KdY2pl+/esBi88QlutsJriWhrp2lPccRRTd3af+K48JE/Qq2y qQ6hlp97jiaB8SYh0rq3ZSl3OXPO/ovk6qksor8lFzu+2SsOtjb3jePuuuBd3WaUUrTU s5Yg== X-Gm-Message-State: AJaThX5BqzpMeU9dn1m6ypInX/tl4PcgloNvYyNK8IzvIWHIsNRP4h9K AG7k404O7z8lWKhR1xryzWSVPuMCqfiviZUIrn8= X-Google-Smtp-Source: AGs4zMbY6x3CbqIMczi0T7gfT1v+8M0Ys5NjbdI7okxs6Igh7I4Eo2ee6FLwKIkoz8tDzVZ601n054PCEuewNosAnWI= X-Received: by 10.55.176.195 with SMTP id z186mr27640005qke.246.1511885804967; Tue, 28 Nov 2017 08:16:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.102.179 with HTTP; Tue, 28 Nov 2017 08:16:44 -0800 (PST) Received: by 10.140.102.179 with HTTP; Tue, 28 Nov 2017 08:16:44 -0800 (PST) In-Reply-To: References: <87shd18c51.fsf@toke.dk> <874lpe8y2f.fsf@toke.dk> From: Jonathan Morton Date: Tue, 28 Nov 2017 18:16:44 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Martin Geddes , bloat Content-Type: multipart/alternative; boundary="94eb2c0702ec58992f055f0d58fe" Subject: Re: [Bloat] Bufferbloat in high resolution + non-stationarity X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 16:16:45 -0000 --94eb2c0702ec58992f055f0d58fe Content-Type: text/plain; charset="UTF-8" I read the paper just now, and skimmed through the thesis to determine that it was talking about the same thing using an order of magnitude more space. It boils down to a Diffserv implementation using a classifier (details handwaved as usual), policers, shapers, and a strict-priority tail-dropping queue. The only noteworthy feature is that the position of the queue's tail depends on the "cherish" metric of each traffic class, which is used to provide differentiation in loss, leaving the strict-priority mechanism to provide "urgency" (delay) differentiation. >From the above, you might reasonably conclude that I'm not very impressed. The paper includes a test scenario versus a plain FIFO and a DRR system. The DRR was weighted with a-priori knowledge of the relative traffic volumes, which in fact would have degraded its performance in delay management. A DRR++ implementation *without* such knowledge would have outperformed it substantially. Toke, reproducing that test load and running it through an unmodified Cake instance would perhaps be enlightening. - Jonathan Morton --94eb2c0702ec58992f055f0d58fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I read the paper just now, and skimmed through the thesis to= determine that it was talking about the same thing using an order of magni= tude more space.

It boils down to a Diffserv implementation using a classifie= r (details handwaved as usual), policers, shapers, and a strict-priority ta= il-dropping queue.=C2=A0 The only noteworthy feature is that the position o= f the queue's tail depends on the "cherish" metric of each tr= affic class, which is used to provide differentiation in loss, leaving the = strict-priority mechanism to provide "urgency" (delay) differenti= ation.

From the above, you might reasonably conclude that I'm n= ot very impressed.

The paper includes a test scenario versus a plain FIFO and a= DRR system.=C2=A0 The DRR was weighted with a-priori knowledge of the rela= tive traffic volumes, which in fact would have degraded its performance in = delay management.=C2=A0 A DRR++ implementation *without* such knowledge wou= ld have outperformed it substantially.

Toke, reproducing that test load and running it through an u= nmodified Cake instance would perhaps be enlightening.

- Jonathan Morton

--94eb2c0702ec58992f055f0d58fe--