First, there is a mistake on the manual page you refer to. In the Configuration Lines section, the rule that invocates the detect-ddos chain is missing, it is only mentioned in the Configuration Explained session:
/ip/firewall/filter/add chain=forward connection-state=new action=jump jump-target=detect-ddos
Second, the firewall rules are in fact a program, in terms that they represent an ordered (sequential) lists of instructions what to do with a packet, so the correct position of a particular rule within each list (chain) is critically important. In particular, the rule that “calls” the detect-ddos chain must be placed before any rule in chain forward of /ip/firewall/filter that accepts packets that match connection-state=new and come from the external networks. This presumably commonly known information is also not reiterated on that manual page.
The connection tracking module of the firewall labels each packet that has a potential to cause establishing of a new connection with connection-state value new. In chain forward of filter, all these packets are sent to chain detect-ddos for processing.
The first rule in the detect-ddos chain invokes a dedicated module, dst-limit, that maintains a hashed list of source and destination address tuples (in this particular case, as the third parameter is set to src-and-dst-addresses). If a packet with an already “known” address tuple hits the rule, the time windows specified using the other parameters are updated for the corresponding record and evaluated, and if the rate of packets with that address tuple is below the limits, the dst-limit module returns a match so the action of the rule, return, is executed. return is a “final verdict” so execution of the ddos-detect chain stops there and the packet processing continues at the next rule in the chain that has invoked the ddos-detect one. If the packet rate (that is 1:1 proportional to connection attempt rate as we only handle connection-state=new packets here) for a given address tuple is exceeded, dst-limit returns a non-match so the action is not taken and processing of the packets in the ddos-detect chain continues by the next two rules tha add the source and destination addresses of the packets they handle to the respective address lists. The actions add-xxx-to-address-list do not constitute final verdicts so after executing the action, the packet continues to the next rule. Once no more rules are left in the ddos-detect chain, the inspection of the packet continues at the next rule in the chain that has invoked the ddos-detect one.
The single rule in chain prerouting of /ip/firewall/raw, if positioned properly, drops any further packets from any of the presumably attacking sources to any of the targeted destinations, including eventual packets that belong to already existing connections. The assumption is that there are not many legal users behind the same public address like the attackers so the collateral damages are not significant. The reason why that drop rule is placed to raw is that raw handles the packet at the very beginning of their journey through the router, even before the connection tracking module, so the minimal amount of CPU is wasted on the packet before it gets dropped.
Now the bad news - all this effort is basically pointless on a home router, as dropping a packet as late as when it has already reached the router can only protect a device behind that router from overload but cannot prevent your download bandwidth from getting wasted. So the whole exercise makes sense on powerful routers that connect actual servers intended for public access, like ISP routers and datacenter routers, if the intensity of the DDoS is low enough that it would not exhaust the available bandwidth, so the attack targets can still receive traffic from actual clients and serve it.
