From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <toke@toke.dk>
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id 32A7A3CB36
 for <cake@lists.bufferbloat.net>; Tue, 17 Apr 2018 11:10:46 -0400 (EDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023;
 t=1523977845; bh=9quWoTlvO3leiAMgv18NbMXLmKoAC41fsEo+yGudkB8=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Gv6u1aMt+DOoJz7Px3AU1s+KR7cFIUoqgcF9D8ul0/FxeBmYCKK0En2aFaZTmc2cA
 06qMJxaNZsTeX4j7lF+yohjjaKXXuFKfI5GiHZQGjzLsm6AjDIjJgjOwFoN30elKL8
 UsQi5GSC+aVW8Ejgy/9PD996DyUEcToMvFhPNfrUIVTOgAIgCaxj4bmH3EE/a2wIW3
 gEpWXP0ZtC/tseStmj1EpEzgV9wq8R+H37QeNoRF3MCBL0gPNvn1oEflDpVHLW2FnX
 LnH0fW99u5SPAjfzkpCEaAMRcMbPZTkFurmiii5DoqJpXs5uW4oArULnnwDNLJdD5D
 F/jei7aPAVHRQ==
To: Luca Muscariello <luca.muscariello@gmail.com>
Cc: Y <intruder_tkyf@yahoo.fr>, Cake List <cake@lists.bufferbloat.net>
In-Reply-To: <CAHx=1M6R=2LzNb+TbKfq-czptoFUf6yHPWp0435s23NnAov4YQ@mail.gmail.com>
References: <87vacq419h.fsf@toke.dk>
 <CAHx=1M6-Jq2MbAZjJSeoUGHZ-fS9+mKeaztMJLJ=Mp4Ux=6NVw@mail.gmail.com>
 <87sh7u3yoa.fsf@toke.dk>
 <mailman.225.1523966725.3573.cake@lists.bufferbloat.net>
 <87muy23tvg.fsf@toke.dk>
 <CAHx=1M44UjWM-vjTLYr4c4h8LBS4C_es1R4cuzYqJwSQjDR6zA@mail.gmail.com>
 <871sfd52q6.fsf@toke.dk>
 <CAHx=1M6R=2LzNb+TbKfq-czptoFUf6yHPWp0435s23NnAov4YQ@mail.gmail.com>
Date: Tue, 17 Apr 2018 17:10:44 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87sh7t3m2z.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Cake] A few puzzling Cake results
X-BeenThere: cake@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Cake - FQ_codel the next generation <cake.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cake>,
 <mailto:cake-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cake>
List-Post: <mailto:cake@lists.bufferbloat.net>
List-Help: <mailto:cake-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cake>,
 <mailto:cake-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2018 15:10:46 -0000

Luca Muscariello <luca.muscariello@gmail.com> writes:

> I will check that later, still unsure.
>
> First guess: the quantum component should influence only how close to a
> fluid bit-wise approximation you are.
> So cake gets closer by automatic adjustment.
>
> The computation of the correction factor should be done by computing the
> probability that a packet
> of a sparse flow loses priority because of the quantum. Bad setting, higher
> probability, ideal setting 0 probability.
>
> So your formula seems still wrong to me...

The formula expresses the conditions under which a flow is guaranteed to
be treated as sparse by the scheduler, under some quite strong
assumptions (most notably that the sparse flow is sending packets at a
fixed rate).

It's derived from the fact that when a packet from the sparse flow
arrives, it (in the worst case) has to wait for the bulk flow packet
that just started getting service (i.e., wait for L/R), after which the
sparse flow itself will get service (in time L_s/R), then it will have
to wait for its queue to pass through a whole round of scheduling (LN/R)
before it can get service as a sparse flow again. Adding these together,
the inter-arrival time between sparse flow packets has to be greater
then (L(N+1)+L_s)/R, which when converted to a rate gives the formula I
mentioned.

You are right, of course, that in the general case it will be different;
but I was talking about the specific case of the fixed-rate sparse flow
here... :)

-Toke