Prioritizing ACK/SYN/FIN/RST packets

For Developers
1

Hello I wanted to ask for help, how to give priority to the ACK / SYN / FIN / RST flags for games

This is good?

iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,ACK,RST,FIN -j DSCP --set-dscp-class CS7

iptables -p tcp --tcp-flags ACK -m length --length :64 -j DSCP --set-dscp-class CS7
iptables -p tcp --tcp-flags SYN -m length --length :64 -j DSCP --set-dscp-class CS7
iptables -p tcp --tcp-flags RST -m length --length :64 -j DSCP --set-dscp-class CS7
iptables -p tcp --tcp-flags FIN -m length --length :64 -j DSCP --set-dscp-class CS7

2

Ayuda ¿?¿?¿?

3

So OpenWrt's default qdisc, fq_codel will already give sparse flows a small boost, and starting TCP flows typically are classified as sparse, so you might not actually see an improvement from doing the explicitly on top of fq_codel...
But if you try optimisations for games, maybe try SQM-scripts? Might not be perfect, but should give you a decent starting point.

4

I have SQM in in CAKE and script in LAYER_CAKE_QOS. but I do not understand what you are trying to insinuate, it happens that I saw in several forums that suggest prioritizing packages such as ACK, SYN, FIN, RST ...

Prioritizing ACK and SYN ... helps me reduce jitter ... games send a lot of ACK and SYN packets.
and i wanted to know what commands to use in the custom rules of ip tables

5

<< Connection establishment:

To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to and listen at a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:

  1. SYN: The active open is performed by the client sending a SYN to the server. The client sets the segment's sequence number to a random value A.
  2. SYN-ACK: In response, the server replies with a SYN-ACK. The acknowledgment number is set to one more than the received sequence number i.e. A+1, and the sequence number that the server chooses for the packet is another random number, B.
  3. ACK: Finally, the client sends an ACK back to the server. The sequence number is set to the received acknowledgement value i.e. A+1, and the acknowledgement number is set to one more than the received sequence number i.e. B+1.

At this point, both the client and server have received an acknowledgment of the connection. The steps 1, 2 establish the connection parameter (sequence number) for one direction and it is acknowledged. The steps 2, 3 establish the connection parameter (sequence number) for the other direction and it is acknowledged. With these, a full-duplex communication is established.>>

.................................................................................

Connection termination:

The connection termination phase uses a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. After the side that sent the first FIN has responded with the final ACK, it waits for a timeout before finally closing the connection, during which time the local port is unavailable for new connections; this prevents confusion due to delayed packets being delivered during subsequent connections.

A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can. The terminating side should continue reading the data until the other side terminates as well.

It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.

..........................................

So in both situations ACK and SYN packets must have big priority. ;)

And if your modem/router has the ability to set up TCP Timeout set it at 90 ms.....your console/server doesn't need to send FIN or RST packet to close the connection....

Your modem will "drop" this connection....so less packets travelling....less internal jitter.

Think of that....

You shoot a person...you send a packet that a "bullet" leave from you (ACK)....server confirms to you with ACK/SYN that "really" you shoot a bullet....now your router must send a FIN packet to close this connection and after a ACK packet!!!!

If your modem can drop these connections it doesn't needs to send packets...less traffic to your network and much easy to handle that.

I hope i do not confuse you.

Copy and paste this from a forum so the idea is understood

6

What I am saying is that with SQM active you already give TCP session initiation packet's a priority boost, as well as equally important DNS queries.... BUT not by virtue of explicitly detecting these packet types with selective filters, but simply exploiting the fact that those packet's tend to be sparse.
No they will not all end up in layer_cake.qos" highest priority tier, but inside each priority tier they will be given priority over bulk packet's. Pretty much the right thing to do, as that will make sure that session intimation of high priority flows will also be prioritized over session initiation of lower priority flows IMHO.
But please let this theoretical observation not stop you from empirically confirmation. Good luck.

1 Like
7

No that does not really confuse me, although I do not fully agree with the logic.
I have seen no proof that games set-up and tear down TCP connections at high rates to begin with, so I really doubt that after starting a game and initiating the network connections, the SYN and SYN-ACK optimization is going to have much effect (and similar for connection tear-down). ACK prioritization is something that had some value in the past. But as I said, both are IMHO better dealt with with generic sparse flow boosting.
If at all, the proposed up-prioritization to CS7 for all ACK, SYN, RST, FIN packets will make all your other users' traffic potentially increase the jitter of your gaming packets. So you might be better of to mark all packets to/from your gaming machine CS7 instead.

8

When I apply these rules in Custom Rules, in games I feel more fluent, but that's why look for someone to tell me if they are well confused