Community discussions

MUM Europe 2020
 
User avatar
jp
Long time Member
Long time Member
Topic Author
Posts: 600
Joined: Wed Mar 02, 2005 5:06 am
Location: Maine
Contact:

queue for better interactive performance

Sun Jan 14, 2007 4:15 am

Just playing around with the queueing options on my own ethernet firewall box at home here (rb153).

I had problems where when uploading (with ssh scp), other interactive traffic crawled and barely worked. I changed the ethernet queue type, made some minor adjustments to it, then setup a mangle to mark ssh traffic, then made a simple queue for the mangle, so the pcq would be applied to it.

Now, multiple ssh activities behave much nicer together. ssh logins work smoothly while ssh scp is uploading. It's a good setup now.

Anybody notice anything I am off about or should have done differently?

Image

Image
 
User avatar
gpienaar
newbie
Posts: 33
Joined: Sun Dec 10, 2006 2:05 pm
Location: South Africa

Sun Jan 14, 2007 10:42 pm

How can the master ask the students for advice? :lol:

You can create a flow first(mark connection) and then from connection mark create packet mark! It just work better according to the clever people!

I would also like to no from the MT guys why this is so! :?

Regards

Mr G
 
User avatar
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Mon Jan 15, 2007 12:09 am

How can the master ask the students for advice? :lol:
You can create a flow first(mark connection) and then from connection mark create packet mark! It just work better according to the clever people!
It works differently, not better.

A connection mark applies for the two way association and is done by the help of connection tracking. Once a packet is marked then the entire conversation is remembered and bares that mark for the entire lifetime of the conversation (two way association).

A packet mark applies only for that specific packet and is not remembered if a new packet in the conversation (two way association) shows up.

However it does not prove granular enough to perform QoS on all packets in an association.
I would also like to no from the MT guys why this is so! :?
I do not work for MikroTik.
Move along. Nothing to see here.
 
User avatar
Equis
Forum Veteran
Forum Veteran
Posts: 888
Joined: Mon Jun 06, 2005 6:48 am

Mon Jan 15, 2007 3:57 am

Hello Sten

What does
However it does not prove granular enough to perform QoS on all packets in an association.
mean?

How can the master ask the students for advice?
Yea, that's what I thought when I seen the poster
 
User avatar
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Mon Jan 15, 2007 4:35 pm

Hello Sten

What does
However it does not prove granular enough to perform QoS on all packets in an association.
mean?

If you give all packets in the same connection the same priority then you can't do things such as prioritize the empty TCP ACK.
Move along. Nothing to see here.
 
User avatar
jp
Long time Member
Long time Member
Topic Author
Posts: 600
Joined: Wed Mar 02, 2005 5:06 am
Location: Maine
Contact:

Mon Jan 15, 2007 5:12 pm

Well, I'm flattered to be considered a master, but I am certainly not omnicient in the ways of Mikrotik. I've just been doing IP networking for 14 years that's all, and have figured out various practical uses for Mikrotik in the last couple.

So it looks like the type of mark (connection versus packet) make some minor difference. But I would have to use connection since i'm using pcq right?

One interface goes to an old breezecom radio (The cobbler's children have no shoes), the other interface goes to my home LAN.

Questions: Any benefit to changing the ethernet queue type to pcq elsewhere instead of pfifo? The only downfall is that I presume I would need connection tracking turned on to use the pcq type of queueing. Any other potential side effects? This sort of fine tuning of queueing probably isn't necessary on high bandwidth links.
 
User avatar
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Mon Jan 15, 2007 6:01 pm

But I would have to use connection since i'm using pcq right?
No, that would be quite wrong.
Questions: Any benefit to changing the ethernet queue type to pcq elsewhere instead of pfifo?
There might be a benefit on other interfaces but it might also cause problems.
The only downfall is that I presume I would need connection tracking turned on to use the pcq type of queueing. Any other potential side effects?
Are you sure you need connection tracking to use PCQ?
Using connection tracking has many side effects.
You might find it refreshingly absurd when someone decides to TCP ACK flood the connection tracking router, or anyone behind the connection tracking router.
This sort of fine tuning of queueing probably isn't necessary on high bandwidth links.
That would be a false presumption.
Move along. Nothing to see here.
 
User avatar
jp
Long time Member
Long time Member
Topic Author
Posts: 600
Joined: Wed Mar 02, 2005 5:06 am
Location: Maine
Contact:

Mon Jan 15, 2007 7:16 pm

well, if connection isn't needed for pcq (I assumed it was because pcq stands for per connection queueing), that makes it more flexible.

I already use connection tracking on edge routers to manage p2p traffic, so connection tracking isn't optional. I do reduce some of the timeouts there, but haven't had problems with connection tracking.

Who is online

Users browsing this forum: ilja, naxos and 129 guests