From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 CA3FC20019F; Sun, 14 Jun 2015 10:38:08 -0700 (PDT) Received: by obcej4 with SMTP id ej4so50738301obc.0; Sun, 14 Jun 2015 10:38:07 -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:content-transfer-encoding; bh=jz6oMGPF7tKfAaETZpPT1+5Hqkg8RqHZ5xMScPpS45A=; b=gqRiO16MLfcL0CDeCN3+FN3blaqtGtDpW0kwiApIdeHKyGmrrSTl6ol5/VJTZeydcj 0eSoPGNKRhT3x0kF0FB4a7SggzXMlcC5dZuQTpf7PPCeCyIbD+FuhgXqqz9E/bCdjAYa Sq2NAmy28GXrQAP5chg8cfKNWa99DyjdVIr+gFsnt2hEy1uxev6BaUi3c3WUeuC0hWM5 VQNrD4IrW3p4iSq4y1IzGl8IU169Es0J18jCv2bQBIq9gmYqxrGbd2s+VaGs24ezGkxd dqAdqV08srWoj+8rs+4feGc6F/qGtAGmAOLF3dSSmI0W8XLC/Z95U3d3+92nAirBbC/G 87jg== MIME-Version: 1.0 X-Received: by 10.60.147.194 with SMTP id tm2mr20465465oeb.75.1434303487731; Sun, 14 Jun 2015 10:38:07 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Sun, 14 Jun 2015 10:38:07 -0700 (PDT) In-Reply-To: <0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com> References: <0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com> Date: Sun, 14 Jun 2015 10:38:07 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net, Alan Jenkins , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Codel] [Cake] openwrt build available with latest cake and fq_pie X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 17:38:37 -0000 adding in codel list. I do think we need a better understanding from observing flow behavior in the fq case than we have. certainly we had a case in the early days where count increased without bou= nd. On Sun, Jun 14, 2015 at 10:19 AM, Jonathan Morton w= rote: > >> On 14 Jun, 2015, at 19:09, Dave Taht wrote: >> >> I do pretty strongly think count - 1 is the rightest thing still. > > I really don=E2=80=99t. Here=E2=80=99s why: > > Every time Codel triggers the dropping state, it will mark or drop at lea= st one packet, and increment count by that number. With count decremented = only by 1 on recovery, it will effectively remain constant *if*, by some mi= racle, the queue empties before the second signal was sent; it cannot decre= ase between episodes unless it resets or wraps. It aint a miracle, it is hopefully within an rtt. > With count decremented by 2 on recovery, it is possible for count to decr= ease slowly in that ideal case, but it=E2=80=99ll remain constant if two si= gnals were sent before the queue cleared, and - this is important - it will= always continue to increase if three or more signals are sent before the q= ueue empties. quibble: queue's latency falls below the target delay. > > If one signal did suffice to clear the queue, then logically the value of= count was irrelevant to that congestion episode and shouldn=E2=80=99t be p= reserved. This is true regardless of the actual reason the queue emptied. > > The problem arises when more than one signal is sent before the queue is = observed to clear. This could be a sign of several distinct network condit= ions: > > - The RTT is longer than interval / sqrt(count), in which case one signal= would still have been sufficient, and the ideal value of count is less tha= n its current value. On non-ECN TCP flows, this results in more retransmis= sions than necessary. > > - The RTT is much shorter than interval / sqrt(count), so the congestion = window is recovering faster than the signalling rate, and count needs to in= crease to compensate for that. > > - There is more than one flow sharing the queue, and it was necessary to = signal to all of them, in which case count should reflect the flow count an= d be capable of adjusting both up and down. > > - The flow is unresponsive, so count should adjust to provide the correct= dropping rate, and RTT is irrelevant. With default parameters, the maximu= m drop rate is presently 25600 pps (which would cause count to wrap after a= few seconds, until I put in the saturating arithmetic). There was some good discussion of things on another list recently (can't remember which) at 100Gig rates. > > How does Codel distinguish between those cases? It can=E2=80=99t - at le= ast, not reliably. So it must allow count to increase until the queue is o= bserved to be controlled, and then decrease count by some other means to co= ver the case where it was overestimated. For this latter phase, count-2 is= obviously insufficient to cope with the case where count is actually corre= ct, but more than one signal per episode is required. > > *That* is why I put in count/2. When resuming the drop phase of codel, it is almost *already* too late to catch that burst incurring the latency. Sometimes I think we need to do away with the count idea and measure slopes of curves instead, and "harmonics". >A multiplicative decrease allows count to stabilise at some value which ad= equately controls the queue, rather than continuously increasing past it. = For the typical cake case where there is one flow per Codel instance and th= e RTT is of Internet scale, this should work at least as well as an additiv= e decrease; in particular, the behaviour is identical where count ended at = 2, 3 or 4 (it can=E2=80=99t end at 1). > Of course, hard data would help to evaluate it, but I do think it=E2=80= =99s theoretically sound. adding in codel list. The brief bits of data I got so far show it failing to control queue, building over time. > - Jonathan Morton > --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast