[Cerowrt-devel] SQM Question #1: How does SQM shape the ingress?

[Dave Taht]

This is one of the harder questions for even experts to grasp: that
ingress shaping is indeed possible, and can be made to work well in
most circumstances.

Mentally I view it as several funnels. You have a big funnel at the
ISP, and create a smaller one on your device. It is still possible for
the big funnel at the ISP to fill up, but if your funnel is smaller,
you will fill that one up sooner, and provide signalling back to make
sure the bigger funnel at the ISP doesn't fill up overmuch, or
over-often. (It WILL fill up at the ISP at least temporarily fairly
often - a common buffer size on dslams is like 64k and it doesn't take
many iw10 flows to force a dropping scenario)

Note: I kind of missed the conversation about aiming for 85% limits,
etc. It's in my inbox awaiting time to read it.

On egress, in cero, you have total control of the queue AND memory for
buffering and can aim for nearly 100% of the rated bandwidth on the
shaper. You have some trouble at higher rates with scheduling
granularity (the htb quantum).

On ingress, you are battling your ISP's device (memory, workload, your
line rate, queuing, media acquisition, line errors) for an optimum,
it's sometimes several ms away (depending on technology), and the
interactions between these variables are difficult to model, so going
for 85% as a start seems to be a good idea. I can get cable up to
about 92% at 24mbit.

I have trouble recommending a formula for any other technology.

In fact ingress shaping is going to get harder and harder as all the
newer, "faster" technologies have wildly variable rates, and the
signalling loop is basically broken between the dumb device (with all
the knowledge about the connection) and the smarter router (connected
via 1gig ethernet usually)

My take on it now (as well as then) is we need to fix the cmts's and
dslams (and wireless, wifi, gpon, etc). DOCSIS 3.1 mandates pie and
makes other AQM and packet scheduling technologies possible. The
CMTSes are worse than the devices in many cases, but I think the
cmts's are on their way to being fixed - but the operators need to be
configuring them properly. I had had hope the erouters could be fixed
sooner than docsis 3.1 will ship...

One interesting note about dslams I learned recently (also from free
who have been most helpful) is that most DSL based triple play
services uses a VC (virtual circuit) for TV and thus a simpleminded
application of htb on ingress won't work in their environment.

(I think it might be possible to build a smarter htb that could
monitor the packets it got into it's direct queue and subtract that
bandwidth from it's headline queues, but haven't got back to them on
that). Also gargoyle's ACC-like approach might work if better
filtered. (from looking at the code last year I figured it wouldn't
correctly detect inbound problems on cable in particular, but I think
I have a filter for that now) I would really like to get away from
requiring a measurement from the user and am willing to borrow ideas
from anyone.

http://gargoylerouter.com/phpbb/viewtopic.php?f=5&t=2793&start=10

Incidentally I liked gargoyle when I tried it. Those of you that have
secondary routers here might want to give it a go. (They did sfqred
briefly then went back to sfq + acc)

In reading what I just wrote I'm not sure how to make any of this
clear to mom. "Scheduling granularity"?

I like what sebastian wrote below, but I think a picture or animation
would make it clearer.

On Sat, Dec 28, 2013 at 11:23 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Rich Brown <richb.hanover at gmail.com> wrote:
>>As I write the SQM page, I find I have questions that I can’t answer
>>myself. I’m going to post these questions separately because they’ll
>>each generate their own threads of conversation.
>>
>>QUESTION #1: How does SQM shape the ingress?
>>
>>I know that fq_codel can shape the egress traffic by discarding traffic
>>for an individual flow that has dwelt in its queue for too long
>>(greater than the target). Other queue disciplines use other metrics
>>for shaping the outbound traffic.
>>
>>But how does CeroWrt shape the inbound traffic? (I have a sense that
>>the simple.qos and simplest.qos scripts are involved, but I’m not sure
>>of anything beyond that.)
>
>         So ingress shaping conceptually works just as egress shaping. The shaper accepts packets at any speed from both directions but limits the speed used for transmitting them. So if your ingress natural bandwidth would be 100Mbit/s you would set the shaper to say 95Mbit/s, so the shaper will create an internal artificial bottleneck just in front of its queue, so that it can control the critical queue.
>         Technically, this works by creating an artificial intermediate functional block device? (IFB), moving all ingress traffic to this device and setting up classification and shaping on that device.
>
> I hope this helps...
>
>         Sebastian
>>
>>
>>_______________________________________________
>>Cerowrt-devel mailing list
>>Cerowrt-devel at lists.bufferbloat.net
>>https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
> Hi Rich,
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html