From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 190843B2A4 for ; Tue, 17 Apr 2018 06:04:31 -0400 (EDT) Received: by mail-qt0-x235.google.com with SMTP id j3so18452179qtn.9 for ; Tue, 17 Apr 2018 03:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VweJkkHwOLN9JYJqN2dz/TrIVyPPEptM9ZRATH4aI/E=; b=tLQJlJ/Cdo5p0Fi/F5pqnhc/Hx82CCPq+7RxUG4/0Pfybpl1qlVF3lEqGOzVyzJNqX y71gXp4hJWoYW0JQ1M5xggedpIlIcjX/lCWonraZvNb1qjmCeprv8SIYDXMCIbUU4GFq p9LYoVlyehjaIihhtAqzdraRgJJxjIBqXDg5e6+QNlsLWO/3JN6cJt/eaYcvaG0ZmL95 g7bJQzCn9kIWd7fbq6Bxb3XckpXLcfD5P6pVdc12+17WbJS8I9zqdr8now1UlpGkW9ou NrEeybmxjR7RugrENN9GeRfddkN1mVSqzkPehsBRF5jIGAqsUk4KjiFQEf2Ac8/rk0Gm 6jgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VweJkkHwOLN9JYJqN2dz/TrIVyPPEptM9ZRATH4aI/E=; b=XulhNPSwdPFobygVvFFX0+/wGSMzoqJn4aodKnpvtS4Ok7oEtr+MFNWFcHvQ2wOdak B2kOe1VI8Kb4/2HPlMm/ncvKp2dA21j5kH0nOJTA4kRmsSpQ4FsOOw5clVq+pi0/7OAw RnUKDiqRNIbZ6F2+6JjU7/GqfDaJhZX+hUO4OtmjSjT/I0Fl9O0BtN+IfVeUVgxuldKt NIXMCwQQ06SSpF0HDvqDsMfWLJgEn4oQH2VWs4j+wDfjvj47efPMWBMvTIaUsO1DBl0O Jaa4WBCwEIrf8uDilL4nu5RWCQcbtEERfSkkFIsHS+If8Z2dJaEtin3zm5kEThFsJl/v nKQQ== X-Gm-Message-State: ALQs6tC3VUiWVuIjmFfYT1wn5ifd43qEtEwmFwrP71spZcu9p7yJ172M YwEdw2FkdD4qIO5CgwkRVP9HxE+Eb7akH6fUbzA= X-Google-Smtp-Source: AIpwx4/eW9UIs39gN3rquAQmhENRZIGeaGN0KcLeDz1ElV8Iddl1hSsW9T8RVxShJZUPb4a72s93B/tDa0EM34zfBa8= X-Received: by 10.200.33.219 with SMTP id 27mr1668788qtz.323.1523959470572; Tue, 17 Apr 2018 03:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.209.134 with HTTP; Tue, 17 Apr 2018 03:04:30 -0700 (PDT) In-Reply-To: <87vacq419h.fsf@toke.dk> References: <87vacq419h.fsf@toke.dk> From: Luca Muscariello Date: Tue, 17 Apr 2018 12:04:30 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Cake List Content-Type: multipart/alternative; boundary="001a113f47a6e54969056a087607" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 10:04:31 -0000 --001a113f47a6e54969056a087607 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 10Mbps/32 ~=3D 300kbps Does the VoIP stream use more than that 300kbps? In the ideal case as long as the sparse flow has a rate which is lower than the fair rate the optimization should work. Otherwise the optimization might not as close to ideal as possible. Luca On Tue, Apr 17, 2018 at 11:42 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > I've been trying to show the benefit of Cake's diffserv mode and came > across a few odd results along the way. Attached are two plots of a test > run with 32 TCP flows competing with a single EF-marked VoIP flow. > > The puzzling points are: > > - There is not difference between Cake in diffserv mode and non-diffserv > mode. For FQ-CoDel, 32 flows (on a 10Mbit link) are clearly too many > to keep the VoIP flow prioritised through the sparse flow > optimisation. This is to be expected. However, Cake (in besteffort > mode) does not show this tendency. Why not? > > - The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel > controls TCP flow latency to around 65 ms, while for Cake it is all > the way up around the 180ms mark. Is the Codel version in Cake too > lenient, or what is going on here? > > -Toke > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > > --001a113f47a6e54969056a087607 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
10Mbps/32 ~=3D 300kbps

Does the VoIP st= ream use more than that 300kbps?
In the ideal case as long as the= sparse flow has a rate which is lower than the fair rate
the opt= imization should work. Otherwise the optimization might not as close to ide= al as possible.

Luca


=

On Tu= e, Apr 17, 2018 at 11:42 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk= > wrote:
I've been trying t= o show the benefit of Cake's diffserv mode and came
across a few odd results along the way. Attached are two plots of a test run with 32 TCP flows competing with a single EF-marked VoIP flow.

The puzzling points are:

- There is not difference between Cake in diffserv mode and non-diffserv =C2=A0 mode. For FQ-CoDel, 32 flows (on a 10Mbit link) are clearly too many=
=C2=A0 to keep the VoIP flow prioritised through the sparse flow
=C2=A0 optimisation. This is to be expected. However, Cake (in besteffort =C2=A0 mode) does not show this tendency. Why not?

- The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel
=C2=A0 controls TCP flow latency to around 65 ms, while for Cake it is all<= br> =C2=A0 the way up around the 180ms mark. Is the Codel version in Cake too =C2=A0 lenient, or what is going on here?

-Toke



_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake


--001a113f47a6e54969056a087607--