From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D688521F30E for ; Thu, 19 Nov 2015 15:54:26 -0800 (PST) Received: by lbblt2 with SMTP id lt2so53167998lbb.3 for ; Thu, 19 Nov 2015 15:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rebjJe/nEBgk6P358Fny+M0mGhTb00zvODf/WlvQ+VQ=; b=JtUljq0s0AOu52oZliTtSfYvdhIAj7AE4DBjMvJIWyRPnlVOGnR3Ep3pgSyuS50mzF Cu5YKItFKJBcLO6MCUZ6lFRrKJsoSYturU0jNF5c8CCyWVx+jDsIb5TNIBVHVnvPM6Kk DMsHMTeJeIezMcCT6uMH/pyj8Ew2lUZsPAMjjKeuHmkX5wfdmdmR3bflmwyQyPii3TJ2 mhSqfBLfL35UDpk7XadmnWyYAvEanTXk7Ny45Ix9+UxGEmS85eYSJrNuoVLQOx5FwfhU 9iaHZPqiXr6q65IQ6dnI/esmJoDjluVCSCqqsoTL3/a+SgpfgzRcpjIdm7ZX9R1rgMb9 e1pw== X-Received: by 10.112.150.225 with SMTP id ul1mr4580974lbb.47.1447977264000; Thu, 19 Nov 2015 15:54:24 -0800 (PST) Received: from bass.home.chromatix.fi (83-245-246-100-nat-p.elisa-mobile.fi. [83.245.246.100]) by smtp.gmail.com with ESMTPSA id j204sm1539024lfd.16.2015.11.19.15.54.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Nov 2015 15:54:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Jonathan Morton In-Reply-To: Date: Fri, 20 Nov 2015 01:54:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34E6EBEB-B9C7-4DB3-94B9-178EC36A6967@gmail.com> References: To: Dave Taht X-Mailer: Apple Mail (2.3096.5) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] strict(er) priority model X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 23:54:50 -0000 > On 19 Nov, 2015, at 11:22, Dave Taht wrote: >=20 > There are a few circumstances where the inherent bandwidth/latency > tradeoffs in cake are trumped by perceived needs for strict priority > queues. It must be emphasised that strict-priority PHB semantics *must* be = accompanied by admission control to prevent abuse. This is not = typically present in Cake=E2=80=99s primary use case, at the consumer = edge of the network, but is a reasonable prerequisite for small-office = uplinks. The existing priority mechanism implementation can approximately support = strict-priority tins with a modification to the tin parameters, setting = both the bandwidth-balance and priority-balance weights equal and very = high (making the threshold for these tins irrelevant). If I changed the = DRR algorithm to always start its scan from the top tin (rather than = remembering its place), the approximation would be closer still. Under = saturated conditions, the modified algorithm would still let a small = amount of normal traffic through, which is probably the correct = behaviour in practice, since it would assist recovery from a DDoS that = managed to bypass admission control. To support VoIP and BGP in this mode, a five-tin scheme would perhaps be = appropriate, with CS7 defining the top tin for routing traffic, and CS6, = EF and VA defining the next one down for VoIP, NTP etc. All other = elevated-priority traffic would then occupy Tin 2. The alternative form of DRR is probably also needed elsewhere in the = code, to support dual host-flow isolation. This would allow me to treat = source hosts and destination hosts independently, greatly simplifying = the choice of default configuration. - Jonathan Morton