Re: [Cake] second system syndrome

[moeller0 <moeller0@gmx.de>]

Hi Dave,

> On Dec 21, 2015, at 13:00 , Dave Taht <dave.taht@gmail.com> wrote:
> 
> in terms of the pppoE stuff needing elevated priority, this is code
> that doesn't exist already and is already handled by the fast/slow
> queue stuff in fq_codel?

So I am still working on and off on my pet idea of shaping on a physical interface (say ge00 in cerowrt parlance) instead of pope-ge00. In that case we actually see all PPPoE-pakets (like PADI, PADO and friends see https://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet#PPPoE_Discovery_.28PPPoED.29) and since all other traffic relies on the status of the “PPP tunnel” these deserve the highest priority. Since they are relatively rare, current fq_codel+htb sort of works okay (well, I try steering everybody to set up sqm on the pppoe interface to actually avoid stepping into this mess), but the shaper will have no information about the maintenance packets at all and hence will slightly undershape the link (undershape as in not shaping sufficiently). As far as I can tell the PPPoE deamon uses LCP echoes to test the link state, now these are only sent once per second (on cerowrt) but miss/drop 5 of these in a row and the PPP connection is teared down and reestablished which takes a while, potentially long enough for all active flows to time out, not nice… Especially since it is possible to drive sqm into drop-tail behavior by simply flooding it, do this for a few seconds and watch PPPoE disconnect...
	
The challenge of shaping on PPPoE instead, is that the kernel accounts different amounts of overhead for ingress and egress there. In case you wonder fq_codel’s maxpacket statistics helped me figuring that out by simply looking at the maxpacket sizes for pppoe-ge00 (maxpacket 1516) and ifb4pppoe-ge00 (maxpacket 1538), which for all I know is just a heuristic and not real proof. The numbers themselves are easily explained given that I have an overhead of 24 bytes specified: 1516-24 = 1492 this is the PPPoE payload (the 8 byte PPP + PPPoE header live inside the classical ethernet MTU) and 1538-24 = 1514 (were the kernel helpfully added part of the ethernet overhead: 6 (dest MAC) + 6 (src MAC) + 2 (ether type) but forgot all about the other ethernet details worth 24 more Byte on the wire).
	All of which makes me wish the kernel would leave the overhead handling completely to user space, because it clearly is doing something complicated (at least given the scarcity of information besides RTF source code). I guess I can fix^Wwork-around this by teaching sqm to handle ingress and egress overhead independently.

Best Regards
	Sebastian