From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::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 D47FF21F36A for ; Thu, 29 May 2014 07:06:22 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so430712vcb.10 for ; Thu, 29 May 2014 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W4YXm5we7E3EiEa/F3krtFwI/3Wrv+/H6hanpI0KWR8=; b=iMbGx0l0vEit3ObwsIRixM+Oyemhn3D+hFzzrloyfUR7vMnktSW1ToMZPKNLn8AxoO 8ZgqPlBz4bJPsuVZdK/vmZs5mhsUt78+amPisGmFcFgXqdulhZ73QnPJ/gThRcQi72r1 69PzvPW6n9CC/JPdW9VFZDXOWBPm9QuJYAiVcRocnOXuM1ZhUBCw3fOa6MEjabb1NNyf tQCtF8sX5YFb6bH95E4AcEJAAWeHvWU9OM/GmkaFh7yNOy4FjcmLYZ4ZCGZ3ga5csbZ4 K1qtLfAGrWhDQXITwG1HtJpbOS7uEv38gMPIUCvejHZQWdO+1SC21yJKdq5qX0ZpSmzR q8OQ== MIME-Version: 1.0 X-Received: by 10.220.69.4 with SMTP id x4mr863542vci.74.1401372381649; Thu, 29 May 2014 07:06:21 -0700 (PDT) Received: by 10.52.14.99 with HTTP; Thu, 29 May 2014 07:06:21 -0700 (PDT) Received: by 10.52.14.99 with HTTP; Thu, 29 May 2014 07:06:21 -0700 (PDT) In-Reply-To: <4F010DC9-309D-4468-AE8B-60EDC59CE028@pnsol.com> References: <20140528093920.9351E406062@ip-64-139-1-69.sjc.megapath.net> <5AB607A3-A4EA-4B6E-A0F6-7FA0ED9B36E7@gmail.com> <4F010DC9-309D-4468-AE8B-60EDC59CE028@pnsol.com> Date: Thu, 29 May 2014 17:06:21 +0300 Message-ID: From: Jonathan Morton To: Neil Davies Content-Type: multipart/alternative; boundary=047d7b3434b001a04b04fa8a6fa7 Cc: Hal Murray , bloat Subject: Re: [Bloat] ipspace.net: "QUEUING MECHANISMS IN MODERN SWITCHES" X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:06:23 -0000 --047d7b3434b001a04b04fa8a6fa7 Content-Type: text/plain; charset=UTF-8 > > Which yields you the classic tail-drop FIFO, whose faults are by now well documented. If you have the opportunity to do something better than that, you probably should. The simplest improvement I can think of is a *head*-drop FIFO, which gets the congestion signal back to the source quicker. It *should* I think be possible to do Codel at 10G (if not 40G) by now; whether or not it is *easy* probably depends on your transistor budget. > > Caveat: this is probably the best strategy for networks that consist solely of long lived, non service critical, TCP flows - for the rest of networking requirements think carefully. There are several, real world, scenarios where this is not the best strategy and, where you are looking to make any form of "safety" case (be it fiscal or safety of life) it does create new performance related attack vectors. We know this, because we've been asked this and we've done the analysis. That sounds like you're talking about applications where reliable packet delivery trumps latency. In which case, go ahead and build big buffers and use them; build the hardware so that AQM can be switched off. I happen to believe that AQM has the more common applications, so it should still be built into hardware whenever practical to do so. Speaking of which, here are a couple more ideas for hardware-simple AQM strategies: RANDOM qdisc, which has no queue head or tail. On dequeue, it delivers a random packet from the queue. On enqueue to a full buffer, it drops random packets from the queue until the new packet will fit. Your primary congestion signal is then packets arriving out of order and with delay jitter, which increases with the average fill of the queue. As a backup, it will revert to dropping packets in an approximately fair manner. HALF MARK qdisc, which is essentially a head-drop FIFO, but when the queue is half-full it begins marking all ECN capable packets (on dequeue) and dropping the rest (according to ECN RFC). I know, it's theoretically inferior to RED, but it's far more deployable. It is also capable of giving a congestion signal without dropping packets, as long as everything supports ECN. Easily generalised into HIGH WATER MARK qdisc where the ECN threshold is not necessarily at half-full. You may also notice that RANDOM and HALF MARK can be implemented simultaneously on the same queue. This is generally true of any two AQM strategies which respectively target packet ordering and packet marking exclusively. You could thus also have RANDOM+Codel or similar. - Jonathan Morton --047d7b3434b001a04b04fa8a6fa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> > Which yields you the classic tail-drop FIFO, whose= faults are by now well documented. =C2=A0If you have the opportunity to do= something better than that, you probably should. =C2=A0The simplest improv= ement I can think of is a *head*-drop FIFO, which gets the congestion signa= l back to the source quicker. =C2=A0It *should* I think be possible to do C= odel at 10G (if not 40G) by now; whether or not it is *easy* probably depen= ds on your transistor budget.
>
> Caveat: this is probably the best strategy for networks that consist s= olely of long lived, non service critical, TCP flows - for the rest of netw= orking requirements think carefully. There are several, real world, scenari= os where this is not the best strategy and, where you are looking to make a= ny form of "safety" case (be it fiscal or safety of life) it does= create new performance related attack vectors. We know this, because we= 9;ve been asked this and we've done the analysis.

That sounds like you're talking about applications where= reliable packet delivery trumps latency. In which case, go ahead and build= big buffers and use them; build the hardware so that AQM can be switched o= ff. I happen to believe that AQM has the more common applications, so it sh= ould still be built into hardware whenever practical to do so.

Speaking of which, here are a couple more ideas for hardware= -simple AQM strategies:

RANDOM qdisc, which has no queue head or tail. On dequeue, i= t delivers a random packet from the queue. On enqueue to a full buffer, it = drops random packets from the queue until the new packet will fit. Your pri= mary congestion signal is then packets arriving out of order and with delay= jitter, which increases with the average fill of the queue. As a backup, i= t will revert to dropping packets in an approximately fair manner.

HALF MARK qdisc, which is essentially a head-drop FIFO, but = when the queue is half-full it begins marking all ECN capable packets (on d= equeue) and dropping the rest (according to ECN RFC). I know, it's theo= retically inferior to RED, but it's far more deployable. It is also cap= able of giving a congestion signal without dropping packets, as long as eve= rything supports ECN. Easily generalised into HIGH WATER MARK qdisc where t= he ECN threshold is not necessarily at half-full.

You may also notice that RANDOM and HALF MARK can be impleme= nted simultaneously on the same queue. This is generally true of any two AQ= M strategies which respectively target packet ordering and packet marking e= xclusively. You could thus also have RANDOM+Codel or similar.

- Jonathan Morton

--047d7b3434b001a04b04fa8a6fa7--