<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Now if you still want to know the technical details...</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>