Re: [Cake] #17

[Sebastian Moeller <moeller0@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]

Hi Jonathan,

On April 13, 2015 2:45:35 AM GMT+02:00, 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 fully agree that simple and automatic are real requirements if we want this to be actually used. I also agree that tc stab has more options than absolutely necessary.

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 am not arguing for the table approach, calculating the size expansion directly might be a bit more costly, but it will scale to GRO packets without requiring special configuration, so certainly your current approach seems better suited for cake than a table.


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

        Well, getting it wrong is bad, but not being able to configure it at all is also going to be wrong for ATM users 100% of the time ;)

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

        Let me be frank here, roughly the right amount is most likely a chiffre for wrong most of the time. As long as you overestimate the overhead you are sacrificing some bandwidth, but underestimating the overhead will make the shaper misbehave...

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

        I fear that this is not going to work to well, some things have complex solutions because the problem is complex.

>
>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 plan!

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.

        If you look at the available tables for valid ATM per packet overheads you will notice them to be quite large, even though none of them includes vlan tags. I want to argue that enumerating them to turn these into symbolic flags is going to be the opposite of simple; hence I would argue for a simple numeric parameter 'overhead'. Maybe default to your automatic estimate unless 'overhead' is specified?


>
>All of this will help with setting cake’s shaper closer to, and
>eventually perhaps *at* the physical link 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.

        With the correct link layer encapsulation values I ran my ATM link with sqm-scripts shaped at 100% egress without induced latency (above the expected), so if sqm scripts can do it so sure can cake :)

Best Regards
        Sebastian

>
> - Jonathan Morton

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 95 bytes --]