From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 B32B73B2A4 for ; Tue, 5 Sep 2017 02:58:19 -0400 (EDT) Received: by mail-qk0-x22f.google.com with SMTP id z143so8764277qkb.3 for ; Mon, 04 Sep 2017 23:58:19 -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=bAGEcGMOHDMuxtNgd8Ol3zKc5jbcO3Mq53lz3Mw1OAs=; b=ifTYvX5bS7D7ScWWD4Vzs3fqJ62GA+NgihtQVUOoxqkH2jaq5R0lyAfB7EHDKbY58d rFpNWfU7eHm6Tlpy8PxuPkgBo38WpWxNN8Quiq1rLN1qlaxe8pgLKlMfMcKlqg8I3Iyz 7aXub25AgCJdEj20DiHItf3N44FxQdL+mYi3bToN/hfMM/t8cUba1hPaCn6lx7T+TVjp u8QPc20M2AcfYxdg7cEa17koXsjY405rXPwzeXcUEiG8bM11ptMxZftGCoN5bIcO9Fnn ZZhIH5vlP4XLtdicX02RJxBCs283BSx8tyzkawklhB7a43HrStPQzXeJg02nMjdkkpkB Uwuw== 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=bAGEcGMOHDMuxtNgd8Ol3zKc5jbcO3Mq53lz3Mw1OAs=; b=g6QyYhDLJ26CUZuxIdBRkZsNpicPy5r8AMNx3BAxzan3KxeEAlmfWwTIa3t7FqqeqD ODlXRRhgdN9A2VxPQuF+hbkSLrxlTFcs0E8CucYO8+eubIV98V/IfhkujxNIH5reFICN cXz5HLihk2SkrLtf7hxXflxyUp48WyLCrmv/Z/rIaR/U8KNV99p9WOfIZyP4JX2alq+v CbKH15n+mkNHMdsn+UCMViaUPXgDuIgVtM3guKWfzEJ5hfCJ7XlPn7vpyrh7eZUCtOYh MERjukSZyp57QbJ3gxkctU98FW16wlqWsyukwKlRM/eYp8QiguocpnI5MJC6a9Z5Dq6E FzUw== X-Gm-Message-State: AHPjjUgEqTRdONocqRiR5Z/krfoPpbzn2X91w9HJPLJeHlOxGNR7GIzA vU8alh5dwj7a8JTVYgWopGkh6b6Efg== X-Google-Smtp-Source: ADKCNb4GCCaINVTkT/ZMWYFR+1kJhHc+/B7OW6aqWkMtv/YvcGpZoSlsN9TdPKeyL0wCsJOPW/CdWHokOKT5ApOC1Ac= X-Received: by 10.55.190.5 with SMTP id o5mr2564379qkf.241.1504594699290; Mon, 04 Sep 2017 23:58:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.177 with HTTP; Mon, 4 Sep 2017 23:58:18 -0700 (PDT) Received: by 10.140.40.177 with HTTP; Mon, 4 Sep 2017 23:58:18 -0700 (PDT) In-Reply-To: References: From: Jonathan Morton Date: Tue, 5 Sep 2017 09:58:18 +0300 Message-ID: To: Dennis Fedtke Cc: Cake List Content-Type: multipart/alternative; boundary="94eb2c0430469510db05586bc0b0" Subject: Re: [Cake] overhead and mpu 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, 05 Sep 2017 06:58:19 -0000 --94eb2c0430469510db05586bc0b0 Content-Type: text/plain; charset="UTF-8" I designed Cake to require as little networking expertise as feasible of the end user. You only really need to know your network topology. So don't overthink this - just set "bandwidth 48Mbit docsis ingress" on your inbound shaper, and "bandwidth (whatever) docsis egress" on the outbound. Why 48 instead of 50? Because Cake needs that when downstream of the bottleneck link, just like any other shaper, so that it controls the bottleneck queue. If your ISP decided to install Cake themselves, they wouldn't need that hack, because they have access to the upstream end of the downlink. Now if you still want to know the technical details... Cake's shaper works by calculating the time it takes to get a given packet through the bottleneck link, measured from the beginning of transmission of that packet to the beginning of transmission of the next packet. To do that, it needs to know the number of bytes per second that the link can carry, and the actual number of byte times occupied by the packet on the wire - not all of which might be included in your typical frame header and payload; we also have to count preamble, checksum, quiet times, etc. These are layer 2 concerns, and in fact Cake normally sees layer 2 packets when attached to an Ethernet interface. Just give it the raw data, and it'll take care of nearly all the nasty calculations and expert knowledge you'd need with most other shapers. The rest of Cake is largely concerned with choosing which packet to deliver next, given the choice among all the packets in its queue. This involves examining layer 3 and layer 4 information within the packet, where available. There are layer 3 (IP) packets without a layer 4 (TCP/UDP) payload, and layer 2 packets without an IP payload, which Cake also has to deal with sanely. - Jonathan Morton --94eb2c0430469510db05586bc0b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I designed Cake to require as little networking expertise as= feasible of the end user. You only really need to know your network topolo= gy. So don't overthink this - just set "bandwidth 48Mbit docsis in= gress" on your inbound shaper, and "bandwidth (whatever) docsis e= gress" on the outbound.

Why 48 instead of 50?=C2=A0 Because Cake needs that when dow= nstream of the bottleneck link, just like any other shaper, so that it cont= rols the bottleneck queue. If your ISP decided to install Cake themselves, = they wouldn't need that hack, because they have access to the upstream = end of the downlink.

Now if you still want to know the technical details...

Cake's shaper works by calculating the time it takes to = get a given packet through the bottleneck link, measured from the beginning= of transmission of that packet to the beginning of transmission of the nex= t packet.=C2=A0 To do that, it needs to know the number of bytes per second= that the link can carry, and the actual number of byte times occupied by t= he packet on the wire - not all of which might be included in your typical = frame header and payload; we also have to count preamble, checksum, quiet t= imes, etc.

These are layer 2 concerns, and in fact Cake normally sees l= ayer 2 packets when attached to an Ethernet interface.=C2=A0 Just give it t= he raw data, and it'll take care of nearly all the nasty calculations a= nd expert knowledge you'd need with most other shapers.

The rest of Cake is largely concerned with choosing which pa= cket to deliver next, given the choice among all the packets in its queue.= =C2=A0 This involves examining layer 3 and layer 4 information within the p= acket, where available.=C2=A0 There are layer 3 (IP) packets without a laye= r 4 (TCP/UDP) payload, and layer 2 packets without an IP payload, which Cak= e also has to deal with sanely.

- Jonathan Morton

--94eb2c0430469510db05586bc0b0--