Είναι το δίκτυο σας γρήγορο, αλλά το download σας όχι; Μπορεί να μην φταίει ούτε ο πάροχός σας αλλά ούτε και ο server από τον οποίο κατεβάζετε, γιατί ενδιάμεσα παρεμβάλλονται πολλά buffers. Το πρόβλημα είναι παλιό αν και το όνομά του "bufferbloat" επινοήθηκε σχετικά πρόσφατα το 2010.
Σε ένα έγγραφο που δημοσιοποιήθηκε στο Association for Computing Machinery, δυο...
ερευνητές προτείνουν έναν νέο μηχανισμό διαχείρισης του queue (ουρά των πακέτων) που αντιμετωπίζει το πρόβλημα αυτό. Ο "Controlled Delay" (Ελεγχόμενης Καθυστέρησης) μηχανισμός, που προτάθηκε από την Kathleen Nichols από το Pollere και του Van Jacobsen από την Parc, έχει σχεδιαστεί για να παρέχει μία "no-knobs" προσέγγιση στην διαχείριση του queue ώστε να ξεπεραστεί το πρόβλημα του "bufferbloat" των δικτυακών συσκευών (routers κλπ).
Το πρόβλημα συνοψίζεται στο Bufferbloat Website ως: "Το buffering των πακέτων δημιουργεί μεγάλη καθυστέρηση (lag), jitter (ανώμαλο ρυθμό) αλλά και ελαττώνει την συνολική απόδοση του δικτύου."
Επειδή η μνήμη είναι φθηνή, εξηγούν οι Nichols και Jacobsen, κάθε κατασκευαστής υποθέτει πως το καλύτερο πράγμα είναι να κάνει τα buffers όσο πιο μεγάλα γίνεται για να διασφαλίσει ότι κανένα πακέτο δεν θα χαθεί. Αυτό όμως ακυρώνει τον πρωταρχικό σκοπό του buffering, που είναι η διαχείριση βραχυπρόθεσμων διακυμάνσεων στον ρυθμό εισερχόμενων πακέτων.
Συγκεκριμένα, αυτοί που υποστηρίζουν το Bufferbloat πιστεύουν ότι το πρόβλημα είναι στο άκρο: επειδή είναι πολύ δύσκολο να προβλέψεις το ιδανικό μέγεθος του buffer για π.χ. έναν DSL router, οι κατασκευαστές τείνουν να κάνουν το buffer όσο είναι δυνατόν μεγαλύτερο. Αυτό όμως ακυρώνει τον εγγενή μηχανισμό αντιμετώπισης συμφόρησης που έχει το TCP, ο οποίος βασίζεται σε πακέτα που απορρίπτονται για να μπορέσει να εντοπίσει τον ιδανικό ρυθμό για την εκάστοτε σύνδεση.
Αντί να απορρίπτουν πακέτα, οι τελικές συσκευές (DSL routers), που έχουν με τεράστια buffers, πρώτα αυξάνουν την καθυστέρηση που ο χρήστης αντιλαμβάνεται: τα πακέτα απορρίπτονται μόνο όταν το buffer γεμίσει και ως εκ τούτου μέχρι τότε ο μηχανισμός του TCP έχει ήδη υπερεκτιμήσει (λανθασμένα) το μέγεθος της σύνδεσης.
Αυτό που χρειάζεται, σύμφωνα με τον Jacobsen και την Nichol, είναι η δυναμική αλλαγή του μεγέθους του buffer στο άκρο, έτσι ώστε το buffer να συμπεριφέρεται όπως πρέπει (να κρατάει αρκετά πακέτα έτσι ώστε να μπορεί να αντιμετωπίσει το jitter), χωρίς όμως να αναγκάζει τον αποστολέα να επιλέγει λάθος TCP window size.
Ο μηχανισμός "CoDel" του Jacobsen και της Nichol, προτείνει την χρήση ενός "τοπικού ελάχιστου queue" (local minimum queue) για να εκτιμήσει το ιδανικό μέγεθος για την εκάστοτε σύνδεση. Κατόπιν προτείνουν την παρακολούθηση της κίνησης της σύνδεσης εάν είναι μεγαλύτερη ή μικρότερη από αυτή την εκτίμηση. Βασίζοντας την εκτίμηση αυτή, όχι σε bytes ή πακέτα, αλλά σε "packet-sojourn time" (δηλαδή την καθυστέρηση τους).
Κάνοντάς το ένα αυτόνομο αλγόριθμο που δεν χρειάζεται ρύθμιση, λένε πως θα είναι κατάλληλο για σύγγχρονα buffers πακέτων και θα μπορούσε να περιληφθεί με ελάχιστο κόστος σε τελικές συσκευές: "πιστεύουμε πως το CoDel μπορεί να εφαρμοστεί αποδοτικά σε σιλικόνη" δήλωσαν.
Οι ερευνητές σχεδιάζουν μία υλοποίηση του CoDel η οποία θα επιτρέψει σε τρίτους να δοκιμάσουν την λύση στην πράξη.
Πηγή: TheRegister
http://www.adslgr.com