From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 57B4F3B2A4 for ; Wed, 29 Mar 2017 13:34:31 -0400 (EDT) Received: by mail-vk0-x235.google.com with SMTP id z204so26451600vkd.1 for ; Wed, 29 Mar 2017 10:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NHyxWK7SBC1v5pbZNWNUgg+UWyK7A0E6LKj+u1rfKgY=; b=DNidrOkk1oz4colFlOTsohuzqDmAx+Teg+dIzIwuEPXJ+VCGlrLCkJB3rp44SUeRxX WmbeQb8SxV6URtK7orFAnu7yL01+CiMzW44KH5ifqCE+aTTkTfT5togsGBJZ+YOil28C c38r7xFiRpaQuAt5sp5JEcdo0SokmOhT/DU+N/qT9BThVOMphvqCAsUune+kWCMw25fn T7UOmwoPtmWrnm2EohyXU0VeToklt6GUVs8rEJdpVEfhU7PYtSOpfC4dICSwqwET2K/g fGm/xEStQ7c+gAh1VNi7DHAYNescnQFzgea7VpRejDitswxTOvfN3rGAcYFhSW1T7FyM cHMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NHyxWK7SBC1v5pbZNWNUgg+UWyK7A0E6LKj+u1rfKgY=; b=EM93sDuImlNZGqFGAOGvwXit3QcRkBeu/U/wawzCTPI1BnMtilIoL0uA7Hk5xz78i8 uhfZsM7uImv2kL8MDjs3DYCnvlq14h7iULEwOF/FGyHFcJ0OS8oVqsUV6ygZOhhhqxzS /jy+LuejZe6poY58tdKLoKlD3+5myvdxOlhOVt6FShctdWaPsPB0C39Rit5ZdU5jHEaq UsAmhi7m91RqIelvo6mHbkp6W8KCmQnuE5OcnZnvvKsTErIGY2U7AR47c98GHeIogOyc /TvDPsWI6eFm5EHuD8vOHqzU595kbk8LoyQyexzpo1EkA5jPWx3qEQAe2rzJopudRhpI KtMg== X-Gm-Message-State: AFeK/H1Gk8GnN7qXJHsR+SPIimmcNbiFHaJHvkUIIRtvg647cFRMr0REBB6lcX2ddGeMO5J/TOanuKocXoOAYA== X-Received: by 10.31.16.69 with SMTP id g66mr738563vki.66.1490808870531; Wed, 29 Mar 2017 10:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.50.146 with HTTP; Wed, 29 Mar 2017 10:34:30 -0700 (PDT) From: vignesh kannan Date: Wed, 29 Mar 2017 23:04:30 +0530 Message-ID: To: cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a11432afc27fb10054be1fdd2 Subject: [Cake] Doubt regarding the Linux implementation of Cake 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: Wed, 29 Mar 2017 17:34:31 -0000 --001a11432afc27fb10054be1fdd2 Content-Type: text/plain; charset=UTF-8 Hello, I am Vignesh, and I am new to this mailing list. I have been going through the Cobalt AQM algorithm implemented in the Cake framework since the last two weeks. Here is the link : The C file : https://github.com/dtaht/sch_cake/blob/master/cobalt.c The header file : https://github.com/dtaht/sch_cake/blob/master/cobalt.h I have also been following the discussions happening about Cobalt on the Bufferbloat mailing list. So I am having problems relating the two sources just mentioned above (the implementation and the discussion). According to my understanding of the Codel algorithm, the count variable (which keeps track of the number of packets dropped in the currently running dropping state) is never really decremented iteratively. However the Cobalt implementation reduces count iteratively (in line 234 of the file cobalt.c) under certain circumstances and this is happening in the function named cobalt_should_drop( ) which is called to determine if Cobalt should drop the packet or dequeue it. It would be great if someone could throw light on what is exactly happening in this function and also a comprehensive explanation of Cobalt itself would be appreciated. Thanks! --001a11432afc27fb10054be1fdd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I am Vignesh, and I am new to = this mailing list. I have been going through the Cobalt AQM algorithm imple= mented in the Cake framework since the last two weeks. Here is the link :


I have also been following the di= scussions happening about Cobalt on the Bufferbloat mailing list. So I am h= aving problems relating the two sources just mentioned above (the implement= ation and the discussion). According to my understanding of the Codel algor= ithm, the count variable (which keeps track of the number of packets droppe= d in the currently running dropping state) is never really decremented iter= atively.

However the Cobalt implementation reduces= count iteratively (in line 234 of the file cobalt.c) under certain circums= tances and this is happening in the function named cobalt_should_drop( ) wh= ich is called to determine if Cobalt should drop the packet or dequeue it. = It would be great if someone could throw light on what is exactly happening= in this function and also a comprehensive explanation of Cobalt itself wou= ld be appreciated.=C2=A0

Thanks!=C2=A0
<= br>


--001a11432afc27fb10054be1fdd2--