Re: [Cake] #17

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan,


On Apr 13, 2015, at 02:45 , Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 13 Apr, 2015, at 03:23, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Ignore my gibberish below, that is almost all required: ceil(len+additional_per_packet_overhead/48)*53 seems the winner ;) Effectively this is what stab should offer, but its implementation with a table has issues if packets are larger than the table estimated…
> 
> The other problem with stab is that the configuration is awfully verbose - pretty much what I was trying to avoid with cake.  

	I agree, “overhead" and "link layer" should be sufficient and link layer can be turned into a simple “atm” flag as you already implemented.

> I’ll admit that a table lookup can be faster than a calculation (under favourable circumstances), but exposing those sorts of implementation details to userspace is just going to give people headaches while they try to figure out what to put and why.

	I think your method is superior to the table as it will work for any packet size, and will not require the user to either specify the table sizing parameters or default to a crazy 64K table to cover GRO.

> 
> That’s a recipe for people (and, more seriously, CPE vendors) getting it wrong.

	Yes, simple wins here, but it needs to be complex enough to actually cover the relevant use cases...

> 
> So cake just has that simple “atm” flag, which adds roughly the right amount of overhead for cell-framing already.  

	The cell framing with the last partly padded cell absolutely requires the correct overhead (well too large an overhead will only cost bandwidth) to work well, other wise the occasional packet will drag in up to 47 bytes of unaccounted bandwidth use.

> Any optimisations to that calculation (which are certainly possible) are an internal matter and not for public consumption.

	There is no reliably way, that I n=know to quickly auto detect the encapsulation overhead; I do have a rather crufty and slow method that will take hours.

> 
> It could be refined by adding an additional, orthogonal setting for non-cell framing overhead, which would be added before the cell-framing calculation; this would allow adding the 8 bytes of PPPoE framing and/or the 2 bytes of Ethernet VLAN tag, for people who want to get it exactly right.  

	I fully endorse this, actually this “overhead” parameter should work independent of the “atm” flag (on my VDSL link I have 16 bytes overhead that needs accounting on top of the ethernet header). For non-arm carriers getting the per-packet overhead wrong is not as terrible, but it will make the shaper suck with small packets...

> Whether these are simple, self-descriptive flags which can be combined for the desired effect, or a numeric parameter which must be set up, is open for discussion.

	Have a look at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ and http://www.faqs.org/rfcs/rfc2684.html (neither of which deals with potential VLAN tags between BRAS and Modem, that are “invisible” to packet captures as they never reach the endusers network, but still cost bottleneck bandwidth); the whole encapsulation issue is a mess that will most likely not lend it self to a small enumeration of encapsulations, so I vote for a) defaulting to 44-14 bytes overhead (this is pretty much the largest I have seen in the wild, but I have not seen much) and b) allowing the user to override this with something along “overhead 26” that will completely replace the 44-14 bytes from above. So have a reasonable default, but allow fine-tuning

> 
> All of this will help with setting cake’s shaper closer to, and eventually perhaps *at* the physical link rate.  

	Just a data point, when my link was still running ADSL2+ I manged to get the egress shaping to work well at 100% of line rate (around 2500 Kbps), so even sqm-scripts could reach that goal. (After the switch to vdsl2 I learned the hard way that my ISP had implemented a BRAS throttle that sort of mooted my attempts to reach 100% of the vdsl line rate).

> The relative lack of bursting from cake’s shaper already allows some of that, since it’s no longer necessary to allow the initial burst from the token bucket to drain from the dumb FIFO downstream.

	Interesting.

Best Regards
	Sebastian

> 
> - Jonathan Morton
>