[Cake] overheads or rate calculation changed?

[Sebastian Moeller]

Hi Jonathan,

> On Jan 7, 2018, at 01:33, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 7 Jan, 2018, at 12:46 am, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>> I thibk cake should offer a mode in which it behaves as all other qdiscs currently do and not do auto correction at all and a mode where it corrects for the right amount, but keeping the current ake cbehavior will not help anybody.... but most likely i misunderstood your proposal in that regard.
> 
> Let me explain a little more clearly, using your example:
> 
> Here "by default" means with no overhead keywords used at all.  Currently, Cake does nothing with the packet lengths by default, acting as though "raw" was specified.

	Yes, I believe we should keep a mode that does exactly that, but this might be done with an explicit keyword IMHO. Not having that would require that cake always does the right thing and as the history of this feature shows, this is hard to guarantee.

> 
> Instead, Cake will act as though "overhead 26" were specified on egress and "overhead 14" on ingress in your case.  
> Unlike its current behaviour, it will recognise that it's actually getting raw IP packets, and won't first attempt to subtract a non-existent header from them.  That's still different from tc-stab behaviour, but probably more useful.

	Why behave like "overhead 26" was specified? The really desired behaviour seems to subtract (skb->len - IP packet size) and neither the 26 nor the 14 where actually added to skb->len. So I a still confused about what you propose cake to report.

BTW do you see a 100% correct way to get to (skb->len - IP packet size)?


> 
> Conversely, with a typical Ethernet interface, it will act as though "overhead 14" were specified on both egress and ingress, and will effectively leave the packet length alone, recognising that there is in fact an Ethernet frame header on the front of the packets handed in.

	Ah, I begin to understand my disconnect; this is not ideal behavior as with the overhead accounting we want to be able to "model" the bottleneck overhead and not only the shaped interface overhead; think shaping for an  IPoA link (IP over ATM) from a non-ATM router connected via ethernet to the ATM-modem, the 14 bytes kernel accounted overhead are neither required nor desired, if I specify overhead 10, the kernel ideally will pass (for a full MTU 1500 packet):
1500 (MTU) + 14 (kernel added MACs/ethertype) + 10 (specified cake overhead) - 14 (remove the kernel-added MACs/ethertype)

Now, if you only talk about the case that the user did not specify an overhead in the cake invocation, using the 1514 skb->len without further modifications, than we violently agree. We really need this "behave like all other qdiscs" mode so that cake can be used with "tc stab" exactly as awkward as all other qdiscs, it would be really unfortunate if cake would require different "tc stab" magic than say HTB+fq_codel.


> 
> If you then specify "overhead 34", you'll get exactly that, relative to the transport-layer packet (that is, IP).

	That is the best thing to do agreed, but from your description above I am not sure about the exact conditions you propose to do that.

> 
> You'll get visibility into this behaviour through the output of the current configuration, which will include an overhead keyword.  And all this assumes that skb_network_offset(skb) *actually* does what I think it does.

	The overhead keyword is nice in that it shows what the user requested, but we really NEED to report also how cake interpreted that request, so we NEED to explicitly report the auto correction value in addition to the requested overhead (and for ease of use we maybe should also report the amount of overhead cake added to skb->len (which equals (requested overhead - auto correction value)))

> 
> What I'm not sure about yet is whether to keep "raw"

	I am not that impressed by the overloading that raw already has (ATM, PTM, overhead...), but the functionality to not-do the auto accounting seems required (unless we guarantee that cake always does the correct thing; and for that we need to explicit;y report what cake "did" and what the user asked it to do).

> and "via-ethernet" with their current meanings -

	THe current via_ethernet behavior seems not requred anymore, ONCE we unconditionally report the amount of auto corrected overhead (which could well be 0).

> as that would probably have a (small) runtime overhead as well as requiring more serious thought into how to organise the configuration interface.  


> Otherwise, I do intend to keep "raw" as a way to reset to the default configuration.

	That is not what raw does ATM, for the via-ethernet mechanism raw is not the default (how a bout a new default compound keyword?)

Best Regards
	Sebastian

> 
> - Jonathan Morton
>