# Software > Linux >  traffic shaping

## dkounal

Βλέπω τώρα τελευταία να σας απασχολεί σοβαρά το traffic shaping...
Η εμπειρία το Ηρακλειο το θεωρει εκ των ουκ ανευ για την σωστή λειτουργία του ασύρματου δικτυου. 
Συγκεκριμένα υπάρχουν οι εξης παράγοντες που εχουν παρατηρηθεί:
α) clients που συνδέονται σε ένα κόμβο και εχουν καλή οπτική επαφή και μικρη αποσταση τείνουν να απορροφουν ολο και περισσότερο bandwidth σε σχέση με χρήστες που συνδεση τους δεν ειναι η καλύτερη. Αυτο κυρίως σε καστασεις max throughput και μπορεί να οδηγήσουν άλους σε αποσύνδεση.
β) Σε επικοινωνία όπου τα πακέτα περνάνε από 2-3 κόμβους από την μια ακρη στην άλλη η συνδεση γινεται ολο και πιο δυσκολη χωρις αυτο να σημαινει οτι οι συνδεσεις μεταξυ των κομβων ειναι κακές απλά εχουν να κάνουμε με μεγαλο lag
γ) Υπάρχουν υπηρεσίες που εχουν time-critical χαρακτηρα, πχ VoIP, video streaming, chating, SSH sessions, shoutcast servers, κλπ. Αυτες πρεπει να εχουν μια προτεραιοτητα ως προς το χρονο διακίνησης.

Να τολμήσω λοιπον να προτεινω ενα μοντελο;

Κατ αρχιν, πρεπει να προβλέψουμε δυο καταστασεις, μια max load οπου η ποσότητα δεδομένων που πρεπει μεταφερθει στην μοναδα του χρονου ειναι μεγαλυτερη από αυτη που μπορει να μεταφερει η ιδια η γραμμη σε φυσικο επίπεδο. και μια δευτερη κατασταση οπου υπαρχει διαθεσιμο bandwidth αλλα δεν χρησιμοποιειται ολο.

Στην δευτερη κατάσταση θα θέλαμε να ορίσουμε μια σειρά προτεραιοτήτων με βάση ip ports βάζοντας σε κάθε υπηρεσία μια προτεραιότητα, αλλα με κατηγοριοποιηση της προτεραιότητας ανά IP port σε τουλάχιστον 6 επίπεδα. (παραγοντας γ) Επίσης θα θέλαμε πακέτα που προερχονται ή που καταλήγουν 2 hops & άνω μακριά να περνουν μια προτεραιότητα παραπάνω από ότι αυτά που που πανε απο client του ενός κόμβου σε client του διπλανου του κόμβου. (παραγοντας β)

Στην πρώτη κατάσταση, εκτός από τα παραπάνω θα θελαμε να μοιράζεται το bandwidth ανα IP εξισου ώστε όλοι να έχουν εξ ίσου και δίκαιη πρόσβαση (παράγοντας α). 

Η κατασταση max load είναι αιτία και άλλων προβλήματων, πχ σε ένα link με dlink 900+ se bridging mode ολα δουλευαν καλά όταν εμπαινε κόφτης στα διακινούμενα πακέτα λίγο πιο κάτω από το bandwidth που μπορούσε να δώσει το link, χωρίς αυτό τα dlink θέλαν reset δυο φορές την μέρα.

Η εμπειρία μας μέχρι τώρα, είναι ότι δεν αρκει το bandwidth limiting που είχαμε βάλει αρχικά, το script για traffic shapping που εχει η distribution του Mick Flemm είναι πρακτιικα μη εφαρμοσιμο σε συνθήκες max load, δουλευει δηλαδή καλύτερα χωρίς αυτό και το εχουμε βγαλει.

Δυο πραγματα υπαρχουν στον ορίζοντα και αυτα ειναι το Linux HTB που πρεπει να περιλαμβανεται στους τελευταιους πυρήνες για το iproute2 και το dummynet του BSD. Αυτή την στιγμή γίνονται κάποιες δοκιμές σε BSD με το dummynet δεν ξέρω όμως πόσο χωρις προβλήματα με drivers και patches αυτών θα είναι μια μετάβαση στο FreeBSD.

Τι εμπειρία υπάρχει σχετικά με αυτό το θέμα;

----------


## papashark

Στο AWMN δεν πολυέχουμε το πρόβλημα που αναφέρεις στο α, αλλά και να το είχαμε, περιόριζετε σε τοπικό επίπεδο και αναλαμβάνει ο ιδιοκτήτης του ΑΡ να τα βγάλει πέρα με τα leecherαρια του.

Στο ΑWMN προβληματιζόμαστε κυρίως με αυτό που λες εσύ στο "β", καθότι επειδή εδώ είναι αρκετά (εώς τελείως) διαφορετική η αρχιτεκτονική του δικτύου μας ενδιαφέρει τι περνάει από τους ΒΒ κόμβους, που περνάνε πολλές φορές και τα 10 hops.....

Τώρα το "γ" που αναφέρεις και την προτεραιότητα συγκεκριμένων πακέτων έναντι άλλων (ανάλογα τις IP ports όπως λες), ε, αυτό είναι το μεγαλύτερο μέρος του traffic shapping που συζητάμε, όμως εδώ δεν μπορείς να πεις σε ποιά πακέτα έρχονται από ποιό μακριά, γιατί όλα τα πακέτα συνήθως είναι από μακριά, υπάρχουν ΒΒ λινκς που περνάει traffic από 10 κόμβους μακρύτερα.......

----------


## dkounal

Σ' ευχαριστώ Πάνο για τις διευκρινήσεις και αισθάνομε οτι λιγο βγαίνω εκτός των δικών μου γνώσεων από εδώ και πέρα.
Σκεφτομουν οτι ο παραγοντας α υπαρχει σε δυο επιπεδα: Σε επιπεδο ευθυνης ενός access point και σε επιπεδο ενός router που δεχεται 2-3 backbone links. Στο επιπεδο του router υπαρχει κατι ανάλογο: πακέτα που ερχονται απο 2 backbone interfaces προωθουνται (εαν δεν υπαρχει traffic shaping) σε ενα τριτο backbone interface με αναλογια που εξαρταται από το ποσο καλες είναι oi wireless συνδεσεις για κάθε interface ή κάνω λάθος;
Ο παράγοντας β για εμας είναι μικρής σημασίας καθότι μεχρι στιγμης όλο to ring δεν είναι 10 hops οποτε "κανένα πρόβλημα" μεχρι στιγμής αλλά αυτό που εμάς είναι 2-3 hops κάνε το 5-8 hops για το awmn και μιλάμε την ίδια γλώσσα.
Αυτές πιστεύω ότι είναι οι διαφορές μας πρακτικά σε επίπεδο traffic shaping, διορθωσε με εάν ξεχνάω κάτι.

----------


## papashark

> Σ' ευχαριστώ Πάνο για τις διευκρινήσεις και αισθάνομε οτι λιγο βγαίνω εκτός των δικών μου γνώσεων από εδώ και πέρα.


Μην ανυσιχείς, έχουμε ξεπεράσει τα δικά μου όρια από ποιό πριν !  :: 

Το "α" δεν συμβαίνει στα ΒΒ λινκς, γιατί εκεί έρχονται δεδομένα από δύο IFs, απλά από το καλό έρχονται πχ 4Mbit και από το μάπα 1 μονάχα. Οπότε στο τρίτο που θα τα προωθήσει τραβάει bandwidth 80-20, εάν το τρίτο δεν έχει ταχύτητα, τότε θα φρενάρει και άλλο το bandwidth που είχαν και τα άλλα δυο. Προσθέτωντας και το banwidth που έχεις από το ΑΡ (πχ άλλα 2) τότε έχεις 7Μbit να περάσουν από ένα Ifs που αντέχει μέχρι 3, οπότε θα περάσει λιγότερο από το μισό από αυτό που έρχετε, και έτσι το μάπα IF από 1 θα περάσει κάτι λιγότερο από 450kbps...

Όμως δεν είναι έτσι εύκολο, γιατί θα υπάρχει και κίνηση μεταξύ του δεύτερου και του πρώτου IF, όπως και μεταξύ του ΑΡ και του 1ου και 2ου IF. 

Από ότι έχει αντιληφθεί στο Ηράκλειο (διόρθωσε με εάν κάνω λάθος), έχετε αρχιτεκτονική ίεραρχική (δέντρου) που ξεκινάτε από ένα κύριο σημείο και ανοίγετε, και το ίδιο όμως συμβαίνει και με τις υπηρεσίες σας, οι όποίες όσο επί το πλήστον ξεκινάνε από το ίδιο ΑΡ (ή κόμβο),

Στο awmn που η κυρίαρχη εφαρμογή είναι το filesharing (και από πλευρά κατανάλωσης bandwidth αλλά και από προτίμησης), έχεις δεδομένα που κυκλοφωρούν προς όλες τις κατευθήνσεις, με μία μικρή τάση για κάποιους κόμβους που προσφέρουν πολλά shares και "ρουφιούντε" περισσότερο.


Από την άλλη (και πάλι εάν γνωρίζω σωστά, η nodedb δεν με βοηθάει ιδιαίτερα για το Ηράκλειο, καθότι δεν γνωρίζω εάν είναι updated), εδώ έχουμε περισσότερες εναλλακτικές διαδρομές από ότι στο Ηράκλειο και έτσι και πιθανότατα περισσότερο διαθέσιμο bandwidth. Εχω δε την εντύπωση ότι αναλογικά έχετε περισσότερους χρήστες από εμάς, έχοντας το αρνητικό ότι είναι τελικοί χρήστες και δεν παρέχουν δεύτερο IF. Έτσι εάν έχετε 100 χρήστες, έχετε περί τους 10 Cx κόμβους, άρα 10%, όταν στο awmn στους 400 χρήστες έχουμε πάνω από 50Ax-Bx και 50 Cx, με αποτέλεσμα το ποσοστό να γίνετε 25% (και πάλι διορθωστε με εάν κάνω λάθος).

Σε καμία περίπτωση δεν θέλω να κάνω κριτική για το εάν είναι σωστή ή λάθος η σχεδίαση του δικού σας δικτύου (ούτε δική μου δουλειά είναι, ούτε ιδία άποψη έχω για το τι ακριβώς έχετε κάνει), αλλά προσπαθώ να σου δώσω να καταλάβεις την διαφορά που υπάρχει στο AWMN με τα περισσότερα δίκτυα, και γιατί δεν είναι εύκολο να αναγάγεις το τι συμβαίνει σε εσάς σε 2-3 hops, να συμβάνει και σε εμάς σε 10....

----------


## racer

Είναι ενδιαφέρουσα ιδεα να μπορούσαμε να αλάζουμε το priority αναλόγος και της απόστασης που πρόκειτε να ταξιδέψει το πακέτο.

Απο όσα γνωρίζω αυτο 'αυτοματα' δέν γίνετε, δέν μου φάινετε απίθανο ομος να μπορέσουμε να το κάνουμε ημιαυτόματα με μερικά βοηθητικά προγραματάκια ... που δέν πρόκειτε κανείς να κάτσει να τα φτιάξει ...  ::

----------


## mindfox

To priority δεν μπορεί να αλλάξει ανάλογα με την απόσταση με την υπάρχουσα δομή του DNS. 

Τι εννοώ με αυτό; 
Υπάρχει το LOC record που επιτρέπει να έχουμε το LONG και LAT του κάθε host στη ζώνη μας. Έτσι λοιπόν, μπορούμε με κάποια scripts να περιορίζουμε το bandwidth ανάλογα με την απόσταση και ανάλογα με την ποιότητα του link (που αν είναι με εξωτερικά interfaces θα πρέπει να μπαίνουν με το χέρι)

Αν και δεν έχω το χρόνο να γράψω κάτι τέτοιο, είναι εφικτό.
Καλή ιδέα και αξίζει να την δοκιμάσουμε, θα το έχω στα υπόψην για όταν βρω λίγο χρόνο.

----------


## dkounal

Η nodedb θελει ξεκαθαρισμα γιατί είναι αρκετά παλαιά σε σημείο που σε λίγο θα μου σβήσει τον κόμβο..... (Δεν εχω και καν απαντησει στα probes που στελνει)
Επισυνάπτω ενα διαγραμμα του δικτύου, οπου είναι θέμα ημερών να τελειώσουν τις τελευταίες δοκιμές 2 λινκς και υπαρχουν και δυο ακομη υποψηφια λινκς με ερωτηματικό. Πιστεύω, οτι παρόλο που έχουμε μια δομή δακτυλίου, που σύντομα θα γίνει κερύθρα, εάν σκεφτείς τις γεωγραφικές διαστάσεις του δικτύου εξακολουθούμε να είμαστε ένα κομματι ενός παζλ που ολόκληρο θα λεγόταν awmn.
Εξακολουθώ να πιστεύω αυτα που εγραψα γιατι τα εχω δει στην πράξη, δεν ξέρω όμως πως να τα δικαιολογήσω τεχνικά και δεν είναι αναλογικό το μοίρασμα αλλά εκθετικό της ποιότητας της γραμμής ή αλλιώς το μάπα λινκ θα δίνει στην καλύτερη περίπτωση 50kbps με την μερίδα του λέοντος στο link με το καλύτερο response.

edit: ta λινκς με διακεκομμές γραμμές είτε προϋπήρχαν στο παλαιό δίκτυο είτε είναι υπό κατασκευή-διερευνηση.

----------


## wiresounds

Θα ήθελα να αναφέρω ότι τις τελευταίες μέρες, δηλαδή από τότε που ο Achille έβαλε το traffic shaping script σε ορισμένους κόμβους συμπεριλαμβανομένου του cslab, έχω πολύ καλή ποιότητα στο web browsing. Δηλαδή έχω ελάχιστες σελίδες να κάνουν time out. Νομίζω ότι εμείς εδώ ήμαστε σε σωστό δρόμο.

----------


## papashark

> Η nodedb θελει ξεκαθαρισμα γιατί είναι αρκετά παλαιά σε σημείο που σε λίγο θα μου σβήσει τον κόμβο..... (Δεν εχω και καν απαντησει στα probes που στελνει)


Κρίμα που δεν την χρησιμοποιείτε, δίνει πάρα πολύ καλή εικόνα του δικτύου. Στην εικόνα που μας έδωσες δεν έχει καθόλου clients....


Τι γίνετε όμως με τις υπηρεσίες που προσφέρετε ? Είναι όπως παλιά, όλοι κοινώς να τραβάτε από το πανεπιστήμειο, ή τώρα υπάρχει content και από τους διάφορες χρήστες ?

----------


## ocean

> Είναι ενδιαφέρουσα ιδεα να μπορούσαμε να αλάζουμε το priority αναλόγος και της απόστασης που πρόκειτε να ταξιδέψει το πακέτο.
> 
> Απο όσα γνωρίζω αυτο 'αυτοματα' δέν γίνετε, δέν μου φάινετε απίθανο ομος να μπορέσουμε να το κάνουμε ημιαυτόματα με μερικά βοηθητικά προγραματάκια ... που δέν πρόκειτε κανείς να κάτσει να τα φτιάξει ...


Πολύ ενδιαφέρουσα άποψη.... για όποιον θέλει να ασχοληθεί λέω τα εξής:

Ενας τρόπος για να δείς απο πόσο μακριά έρχεται ενα πακέτο ειναι να εξετάσεις το TTL field του πακέτου. Αντιγράφω απο το RFC 1122, Section 38:




> The TTL field has two functions: limit the lifetime of TCP segments (see RFC-793 [TCP:1], p. 28 ), and terminate Internet routing loops. *Although TTL is a time in seconds, it also has some attributes of a hop- count, since each gateway is required to reduce the TTL field by at least one.*


Αν λοιπόν βασιστούμε σε αυτό, το επομενο πράγμα που χρειαζόμαστε ειναι ένα firewall ικανό να διαβάζει το TTL field, για να μπορεί να κάνει intercept τα ζητούμενα πακέτα και να περνάει απο ένα traffic shaper. Στο IPFW του FreeBSD αυτο το option Υπάρχει (quote απο το man page του IPFW):




> ipttl ttl-list
> Matches IP packets whose time to live is included in ttl-list,
> which is either a single value or a list of values or ranges
> specified in the same way as ports.



Φαντάζομαι οτι αυτό γίνεται και σε άλλα firewalls/λειτουγικά.
Οποιος έχει όρεξη ας το δοκιμάσει ....

----------


## dkounal

> Κρίμα που δεν την χρησιμοποιείτε, δίνει πάρα πολύ καλή εικόνα του δικτύου. Στην εικόνα που μας έδωσες δεν έχει καθόλου clients....
> 
> Τι γίνετε όμως με τις υπηρεσίες που προσφέρετε ? Είναι όπως παλιά, όλοι κοινώς να τραβάτε από το πανεπιστήμειο, ή τώρα υπάρχει content και από τους διάφορες χρήστες ?


Η κάθε κύκλος που βλέπεις έχει απο 1 εως 25 ταυτοχρονους μονιμους χρήστες αναλόγως θέσης και ηλικίας. Ιντερνετ εχει πάψει να κυκλοφορεί εδώ και μήνες και τώρα τελειώνουν τις δοκιμές στο VPN server έχει τοποθετηθεί την περασμένη εβδομάδα για να αρχισει και η πιλοτική λειτουργία του.

Εχουμε, DC++ (~950GBshare max εχω πετυχει), IRCd, 7-8 ftp servers, 1 shoutcast, 1 CS, voip καποιοι μεταξύ μας, εσωτερική web σελιδα. Αυτα προς το παρόν.

----------


## Ad-Hoc

Ocean η δυνατότητα υπάρχει αυτή απότι νομίζω και σε Linux χρησιμοποιώντας iptables 

π.χ iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64

Επίσης με την χρήση του "Mark target" μπορούμε να μαρκάρουμε πακέτα χρήσης ssh και να ορίσουμε την ταχύτητά τους σύμφωνα με το mark που έχουνε. Προφανώς συνοδεύεται με iproute2.

π.χ iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2

Όπως επίσης

iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10

Αυτά θεωρητικά γιατί πρακτικά δεν τα έχω δει να δουλεύουνε και δεν έχω δοκιμάσει τίποτα από αυτά.
Το σίγουρο είναι με το table mangle (-t mangle) γίνεται το όλο τσεκούρεμα σε TOS και TTL όπως και μαρκάρισμα σε διάφορα πακέτα για advanced routing με TC.

----------


## paravoid

> Ocean η δυνατότητα υπάρχει αυτή απότι νομίζω και σε Linux χρησιμοποιώντας iptables 
> 
> π.χ iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64
> 
> Επίσης με την χρήση του "Mark target" μπορούμε να μαρκάρουμε πακέτα χρήσης ssh και να ορίσουμε την ταχύτητά τους σύμφωνα με το mark που έχουνε. Προφανώς συνοδεύεται με iproute2.
> 
> π.χ iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2
> 
> Όπως επίσης
> ...


Τα 2 τελευταιά χρησιμοποιούνται από το πολυαναμενόμενο traffic shaping  ::

----------


## dkounal

Πόσες κατηγορίες προτεραιοτήτων μπορούμε να έχουμε; 
Μπορούμε δηλαδή να βάλουμε 10 διαφορετικές κατηγορίες και να αντιστοιχίζουμε σε καθεμια 2-3 διαφορετικές υπηρεσίες βασισμένες σε ΙP ports;

----------


## Mick Flemm

Απ' όσο ξέρω το TOS παίρνει συγκεκριμένες τιμές και συνήθως 2-3 (0.2.4.8.16) διορθώστε με αν κάνω λάθος.

TOS match v1.2.6a options:
[!] --tos value Match Type of Service field from one of the
following numeric or descriptive values:
Minimize-Delay 16 (0x10)
Maximize-Throughput 8 (0x0 :: 
Maximize-Reliability 4 (0x04)
Minimize-Cost 2 (0x02)
Normal-Service 0 (0x00)

----------


## Brat3

Αν δεν "πεις" στους routers σου να "χρησιμοποιουν" σωστά τα TOS bytes όσο και να τα αλλάξεις δεν θα δεις διαφορά. Οπότε και να κάνεις MARK από τα linuxo-κουτα 8α χρειαστεί στη συνέχεια να χρησιμοποιήσεις QOS τεχνικές στους routers.

----------


## racer

> Πόσες κατηγορίες προτεραιοτήτων μπορούμε να έχουμε; 
> Μπορούμε δηλαδή να βάλουμε 10 διαφορετικές κατηγορίες και να αντιστοιχίζουμε σε καθεμια 2-3 διαφορετικές υπηρεσίες βασισμένες σε ΙP ports;



Ανάλόγος τον εξοπλησμό, σίγουρα παραπάνω απο 10  ::

----------


## Achille

> Αν δεν "πεις" στους routers σου να "χρησιμοποιουν" σωστά τα TOS bytes όσο και να τα αλλάξεις δεν θα δεις διαφορά. Οπότε και να κάνεις MARK από τα linuxo-κουτα 8α χρειαστεί στη συνέχεια να χρησιμοποιήσεις QOS τεχνικές στους routers.


Όλοι οι σοβαροί routers που σέβονται τον εαυτό τους λαμβάνουν υπόψιν τους τα TOS fields. Αν στο Linux δεν ορίσεις καθόλου ουρές QoS, η default ουρά είναι η pfifo_fast, η οποία το μόνο που κάνει είναι να προωθεί τα πακέτα με το ανάλογο TOS ψηλότερα.

Δεν είναι λύση στο πρόβλημα απλά να μαρκάρουμε τα πακέτα με TOS, αλλά σίγουρα βοηθάει όταν περνάνε τα πακέτα από routers που δεν είναι σεταρισμένοι ανάλογα.

----------

