Já bych ještě úplně na začátek dal JUMP podle toho, jestli je to UP nebo DOWN. Jinak kdyby to byla veliká síť, mohlo by to klidně mít dvě úrovně (např. nejprve skok s maskou /16 a druhý s maskou /24). Další možností pro drobnou optimalizaci je řazení pravidel podle datového toku (tahači nebo prostě jen velké tarify nahoru). Úplně ideální řešení by pak bylo, kdyby to co nejoptimálněji generoval skript.
Nevím, jestli tady zaznělo, v čem je vlastně ta optimalizace. Vezměme např. síť s 1000 uživateli. Pokud budeme mít neoptimalizovaný "plochý" mangle, bude obsahovat 2000 pravidel (up+down), každý průchozí paket se těmi pravidly pohrne shora dolů = s každým se teoreticky udělá průměrně 1000 porovnávacích operací (s některým jedna, s některým 2000 - z tohoto pohledu je lepší mít nahoře pravidla pro DOWN a velké tarify).
Pakliže je těch 1000 uživatelů rozloženo řekněme do 20ti subnetů /24 a udělá se nejprve jump podle UP/DOWN (2 řádky), následně jump podle /24 (20 řádků) a následně koncové markování (průměrmě 1000/20=50 řádků) bude se na každý paket prohánět průměrně 1,5+10+25 pravidly = 36,5 porovnávacích operací. To je proti původním 1000 sakra rozdíl.