Since we now are required to disclose our network management practices on
our website and point of sale, I have found that simple is better. Try and
be transparent about anything complex, and it sounds bad even if done with
good intent. I'm not saying what you propose would violate Open Internet
rules, but that the transparency requirement makes it more trouble than it's
worth.
If people max out their upstream, the best answer may be either (1) don't do
that, or (2) upgrade to a higher plan.
Also, the people who say router QoS is the answer to everything mostly lie,
since it really only helps prioritize upstream traffic. But that's what you
are citing as the problem to be solved. The nice thing about prioritizing
traffic in the router is that it's the customer's choice, not the ISP. So
maybe the customer needs to prioritize his upstream traffic before it hits
the Internet connection.
That's assuming the problem isn't his WiFi. I see customers with things
like Dropcams that transmit constantly but have poor WiFi signals because of
location and poor antennas, and they really mess with the WiFi performance.
Either because of low modulation, or hidden node problem. That's a case
where it might make sense to use a dual or tri band router and make
intelligent decisions about what devices use what band.
-----Original Message-----
From: Matt
Sent: Wednesday, September 30, 2015 11:37 AM
To: [email protected]
Subject: Re: [AFMUG] Mikrotik Queue Types
Not sure what queue type PPPoE defaults too, likely default-small
which seems to be pfifo with 10 packets on my pppoe server. What I am
thinking is of a queue type that would be rate-limiting say an online
backup at say 0.5 megabits per second upstream, the max for there
pppoe profile. A different new stream would come along and the queue
type would push that one initially to front of queue so as to give it
a fair chance to get started while pushing existing connections to
back of queue. Not sure if that makes sense or is possible. Even if
it is it might simply max out the CPUs on the CCR mikrotik router
keeping track of all this for hundreds of pppoe sessions.
On Wed, Sep 30, 2015 at 11:16 AM, Ken Hohhof <[email protected]> wrote:
I thought Mikrotik PPPoE queues were always default-small, or is that
because I use RADIUS?
Personally I use RED but I think there are several choices that will work
well, as long as you don't make the queue size too small. (10 packets is
too small, around 50 is good.)
I suspect your users who max out their upstream are just seeing what
happens
when you max out your upstream, it will make things seem sluggish even if
there is plenty of downstream left. That's how the Internet works. Not
sure you're doing anything wrong.
BTW, the reason I use RED is that as the queue fills up, the probability
of
a packet being dropped increases, hopefully invoking TCP congestion
control
to slow the rate of the traffic gracefully. That said, it's probably not
a
popular choice.
-----Original Message----- From: Matt
Sent: Wednesday, September 30, 2015 10:32 AM
To: [email protected]
Subject: [AFMUG] Mikrotik Queue Types
Saw in the ePMP knowledge base that they recommend changing queue type
from default to wireless-default.
In one of my mikrotik pppoe servers I look and see default is pfifo
with 50 packets. Wireless-default is sfq with 5s and 1514bytes.
What would advantages or reason for the change?
I don't user epmp yet but on my PPPoE server I frequently have
complaints from users that have there upstream maxed out by one thing
or another complain about there connection. I wander if switching to
sfq might help there? Or it might simply max my Mikrotik CPUs out.
