Πολιτική ISP απέναντι στις εταιρίες VoIP

[trojy]

Μετά την 06/09/05, και αφότου είχα περί τους 2 μήνες αξιόλογης χρήσης της Voipbuster, ξεκίνησα να έχω προβλήματα στην χρήση της. Για την ακρίβεια, εκείνοι με άκουγαν αμέσως και πολύ καλα, ενώ εγώ τους άκουγα σαν μαστουρωμένους.
Κάνοντας ένα απλό test, ping -t www.sportnet.gr , και παράλληλα τρέχοντας το πρόγραμμα της voipbuster (ας πούμε το 2.0 built 166 - το οποίο δεν έχει σημασία γιατί το ίδιο γίνεται και με άλλα προγράμματα ή με τη χρήση του Asterisk) θα παρατηρήσετε ότι.
1. Αρχικα οι χρόνοι είναι αρκετά καλοί
2. Στη συνέχεια υπάρχει σταδιακή αύξηση του ping response ( 60 ms -->100 -->500 -->1000-->10000 --->30000). H αύξηση αυτή είναι ανεξάρτητη του traffic που γίνεται (~3 kb/s up/down).
3. Έπειτα παρουσιάζεται packet loss (γύρω στα ~6-7 πακέτα).
4. Χάνεται προσωρινά η σύνδεση με το bbras/ ISP.


Θεωρώ δεδομένο ότι είτε ο ΟΤΕ (?) είτε η 4νετ (?) έχουν βάλει το χέρι τους για να περιορίσουν ανταγωνιστικές εταιρίες Voip. Δεν δικαιολογείται με κάποιον άλλον τρόπο αυτό το πρόβλημα. Θα ήθελα να γνωρίζω αν αντιμετωπίζετε το ίδιο πρόβλημα, και σε ποιο dslam συνδέεστε.
Αν υπάρχει αυτή η πατερναλιστική συμπεριφορά από τη 4νετ ηθελημένα, είναι κατακριτέα και θα πρέπει να δημοσιοποιηθεί.

[anon]

Κάνοντας ένα απλό test, ping -t www.sportnet.gr

Το VoIP χρησιμοποιεί UDP. Δοκίμασε ένα ftp transfer. Εαν έχουν κάνει traffic shaping στο Voice πιθανότερο να επηρεάζει όλο το UDP. Οπότε θα φανεί. Ομως αναφέρεις να αυξάνουν τα responses στο ping. To ping είναι ICMP, άλλο πρωτόκολλο, και ους ενδιαφέρει να "δείχνει"καλούς χρόνους. Αρα μάλλον κάποιο πρόβλημα έχεις με ΟΤΕ (DSLAM).

[frap]

Το ftp είναι TCP όχι UDP...

[gpap1973]

Δεν μιλάμε για Traffic Shaping αλλά για αυξηση του delay (διαφορετικό πράμα).
Μπορείς να έχεις αυξημένα delays αλλα η σύνδεση σου να πέζει άψογα στο full της.
Το voip για να παίζει θέλει το πολύ 500ms. Οπότε βάζοντας +500ms σε όλα τα voip
που δεν πάνε σε εμας κάνουμε τον ανταγωνισμό να μοιάζει κακής ποιότητας.

Με την πείνα που έχουν οι ελληνικοί ISPs δεν θεωρώ απίθανο να το έχουν κάνει.

[anon]

Το ftp είναι TCP όχι UDP...

TCP είναι το control κομμάτι, δηλαδή τις εντολές που δίνεις. H μεταφορά όμως γίνεται με udp.

[cassidy]

Trojy δε νομίζω πως πηγαίνει τόσο μακριά το πράμα. Αν προσέξεις άλλοι στο forum το έχουν το πρόβλημα κι άλλοι δεν το έχουν. Οπότε δε μπορούμε να μιλάμε για πολιτική μιας εταιρίας ή ενός οργανισμού.
Στις προβληματικές συνδέσεις (πίτα dslam) παρατηρείται συνήθως το φαινόμενο αυτό.
Βασικά συμπτώματα
α) μεγάλο ping στο πρώτο hop αν κάνεις tracert οπουδήποτε
β) προβλήματα σε p2p που χρησιμοποιούν πολλές συνδέσεις
γ) max packets/sec που δε ξεπερνούν τα 25 (υπό φυσιολογικές συνθήκες είναι πάνω από 80)

Ειδικά το γ, επηρέαζει τις realtime εφαρμογές γιατί ενώ δε χρειάζονται bandwidth χρησιμοποιούν πολλά και μικρά πακέτα (udp). Οπότε παιχνίδια/voip/video conference ΓΙΟΚ, τουλάχιστον τις ώρες αιχμής. Τα παράπονά σου στον ΟΤΕ.

[anon]

Δεν μιλάμε για Traffic Shaping αλλά για αυξηση του delay (διαφορετικό πράμα).

Με traffic shaping δημιουργείται delay. Εαν δώσω προτεραιότητα χαμηλότερη στο ICMP και γίνεται χρήση της γραμμής απο τα πιο πάνω προτεραιοποιημένα πρωτόκολλα, μοιραία τα πακέτα ICMP θα περιμένουν και θα εμφανίζουν καθυστέρηση που δεν θα έχουν άλλα (πχ SSH). Επίσης το μπούκωμα της γραμμής δημιουργεί delay μιας και δεν μπορούν να περάσουν όλα την γραμμή. Φαντάσου ένα πακέτο σαν ένα αυτοκίνητο, και την σύνδεση στο Internet σαν ένα δρόμο. Οσο πιο μεγάλη σύνδεση έχεις τόσο πιο φαρδύς είναι ο δρόμος και με μεγαλυτερο όριο ταχύτητας. Αρα αν στείλεις ένα ICMP πακέτο, και υπάρχει μποτιλιάρισμα, τότε θα έχεις και μεγαλυτερη καθυστέρηση. Αυτό όσο πιο απλα γίνεται γιατι διαφορετικά θα πρέπει να επεκταθούμε και στους συνδιασμούς MTU/bandwidth, encoding frame rate κλπ.

Το voip για να παίζει θέλει το πολύ 500ms. Οπότε βάζοντας +500ms σε όλα τα voip
που δεν πάνε σε εμας κάνουμε τον ανταγωνισμό να μοιάζει κακής ποιότητας.

Πολλά λες. 250 ms είναι το μέγιστο που προτείνουν (πχ Cisco). Επίσης παίζουν και πολλά άλλα ρόλο, που θα επεκταθούμε πολύ. Εαν έχεις πάνω απο 250ms, τότε υπάρχει η διαφορά καθυστέρησης της ομιλίας. Εαν έχεις 250ms απο traceroute, τότε βάλε και άλλα 50-150 encoding/decoding και άλλα, και φτάνεις στα 400ms, δηλαδή σχεδόν μισό δεύτερο. Απο εκεί και πάνω είναι το ενοχλητικό φαινόμενο να μιλάς και ο άλλος να ακούει με καθυστέρηση (στυλ walkie-talkie)

[chatasos]

Το traffic shaping προκαλεί delay όταν ενεργοποιείται
Το voip θέλει max 150ms (one-way) για να παίξει χωρίς καθυστέρηση
To ftp (control & data) είναι στο 99% των περιπτώσεων tcp

[BoGe]

Δεν ξέρω αν είναι τυχαίο, αλλά στο forum πάντος έχουν και άλλοι αναφέρει πρόβλημα με FORTHnet.

[chatasos]

Κάνοντας ένα απλό test, ping -t www.sportnet.gr , και παράλληλα τρέχοντας το πρόγραμμα της voipbuster (ας πούμε το 2.0 built 166 - το οποίο δεν έχει σημασία γιατί το ίδιο γίνεται και με άλλα προγράμματα ή με τη χρήση του Asterisk) θα παρατηρήσετε ότι.
1. Αρχικα οι χρόνοι είναι αρκετά καλοί
2. Στη συνέχεια υπάρχει σταδιακή αύξηση του ping response ( 60 ms -->100 -->500 -->1000-->10000 --->30000). H αύξηση αυτή είναι ανεξάρτητη του traffic που γίνεται (~3 kb/s up/down).
3. Έπειτα παρουσιάζεται packet loss (γύρω στα ~6-7 πακέτα).
4. Χάνεται προσωρινά η σύνδεση με το bbras/ ISP.

Παρόμοιο πρόβλημα έχει παρατηρηθεί σε συγκεκριμένα dsl modems όταν το voip pvc είναι πολύ μικρό ή έχει σεταριστεί μικρός αιρθμός burst cells.

Ενώ το x modem έπαιζε voip (1 κλήση) μια χαρά σε pvc 64/64, στο y modem (με ίδιο codec) έπρεπε να αυξήσεις το pvc σε 128/128 ή να μεγαλώσεις τον αριθμό των burst cells για να δουλέψει χωρίς καθυστέρηση.

Σίγουρα μιλάμε για διαφορετική περίπτωση από την δική σου, αλλά με ακριβώς τις ίδιες παρενέργειες. Εγώ προσωπικά στην περίπτωση σου, θα έκλινα προς πρόβλημα στο επίπεδο του atm.

Θα σου πρότεινα όμως να συντάξεις ένα email με τις παρατηρήσεις σου τεκμηριωμένες (με παραδείγματα) και να το στείλεις στον provider σου.

[gpap1973]

Με traffic shaping δημιουργείται delay. Εαν δώσω προτεραιότητα χαμηλότερη στο ICMP και γίνεται χρήση της γραμμής απο τα πιο πάνω προτεραιοποιημένα πρωτόκολλα, μοιραία τα πακέτα ICMP θα περιμένουν και θα εμφανίζουν καθυστέρηση που δεν θα έχουν άλλα (πχ SSH). Επίσης το μπούκωμα της γραμμής δημιουργεί delay μιας και δεν μπορούν να περάσουν όλα την γραμμή. Φαντάσου ένα πακέτο σαν ένα αυτοκίνητο, και την σύνδεση στο Internet σαν ένα δρόμο. Οσο πιο μεγάλη σύνδεση έχεις τόσο πιο φαρδύς είναι ο δρόμος και με μεγαλυτερο όριο ταχύτητας. Αρα αν στείλεις ένα ICMP πακέτο, και υπάρχει μποτιλιάρισμα, τότε θα έχεις και μεγαλυτερη καθυστέρηση.

Βασικά,
δεν κάθομαι να φανταστώ τίποτα. Προφανώς με κάθε congestion έχουμε delays (όπως γλαφυρά περιγράφεις). Αλλά εγώ μίλησα για (ανεξάρτητη) διαχείρηση του delay. Congestion και delays δεν ταυτίζονται πάντα. Και ο "trojy" ρωτά μόνο για delays σε μια σύνδεση που παίζει καλά (άρα δεν έχουμε congestion, τουλάχιστον στο link του).

Αυτό όσο πιο απλα γίνεται γιατι διαφορετικά θα πρέπει να επεκταθούμε και στους συνδιασμούς MTU/bandwidth, encoding frame rate κλπ.

Εγώ πάλι λέω να μην επεκταθούμε σε τίποτα. Η ερώτηση ήταν θεωρητική και η απάντηση μου
σαφέστατη: "Ο ISP μπορεί να σου βάλει delay (χωρίς απαραίτητα να έχεις congestion) σε ορισμένα πακέτα που κρίνει σκόπιμο". Αν έχει βάλει limit ή delay, δεν το ξέρω γιατί δεν έχω πρόσβαση για να δω.

Ενας ISP που σου βάζει limit κατώτερο από αυτό που πληρώνεις απλά παρανομεί. Αν σου βάζει delay είναι 100% νόμιμος αφού η γραμμή σου παίζει στα full της.
Επαναλαμβάνω οτι δεν ξέρω τι και αν το έχουν κάνει, εικασίες κάνω.

Πολλά λες. 250 ms είναι το μέγιστο που προτείνουν (πχ Cisco). Επίσης παίζουν και πολλά άλλα ρόλο, που θα επεκταθούμε πολύ. Εαν έχεις πάνω απο 250ms, τότε υπάρχει η διαφορά καθυστέρησης της ομιλίας. Εαν έχεις 250ms απο traceroute, τότε βάλε και άλλα 50-150 encoding/decoding και άλλα, και φτάνεις στα 400ms, δηλαδή σχεδόν μισό δεύτερο. Απο εκεί και πάνω είναι το ενοχλητικό φαινόμενο να μιλάς και ο άλλος να ακούει με καθυστέρηση (στυλ walkie-talkie)

Προφανώς, αλλά ακόμα και στο μισό δευτερόλεπτο, το παλέυεις (να μιλήσεις).

[BoGe]

Θεωρώ δεδομένο ότι είτε ο ΟΤΕ (?) είτε η 4νετ (?) έχουν βάλει το χέρι τους για να περιορίσουν ανταγωνιστικές εταιρίες Voip. Δεν δικαιολογείται με κάποιον άλλον τρόπο αυτό το πρόβλημα. Θα ήθελα να γνωρίζω αν αντιμετωπίζετε το ίδιο πρόβλημα, και σε ποιο dslam συνδέεστε.
Αν υπάρχει αυτή η πατερναλιστική συμπεριφορά από τη 4νετ ηθελημένα, είναι κατακριτέα και θα πρέπει να δημοσιοποιηθεί.

Κάνε το εξής:
Πάρε ένα demo από άλλους ISP, και αν με άλλους δεν έχεις πρόβλημα τα φταίει η FORTHney, αλλιώς ο ΟΤΕ. Μπορεί και οι 2 βέβαια.
Αν τελικά το κάνεις, πες μας μετά τα αποτελέσματα.

[anon]

Βασικά,
δεν κάθομαι να φανταστώ τίποτα. Προφανώς με κάθε congestion έχουμε delays (όπως γλαφυρά περιγράφεις). Αλλά εγώ μίλησα για (ανεξάρτητη) διαχείρηση του delay. Congestion και delays δεν ταυτίζονται πάντα. Και ο "trojy" ρωτά μόνο για delays σε μια σύνδεση που παίζει καλά (άρα δεν έχουμε congestion, τουλάχιστον στο link του).

Δεν ξέρω πως το μετράει. Ετσι αναφέρω πως μπορεί να δημιουργηθεί delay. Το delay μπορεί να είναι και απο την πλευρά ΟΤΕ/ISP (το πιθανότερο). Ειδικά όταν αναφέρει ότι συνεχώς αυξάνουν οι χρόνοι στο ping, μέχρι που χάνονται πακέτα, αυτο μοιάζει σαν πρόβλημα σύνδεσης. Τώρα απο την πλευρά του χρήστη, απο την πλευρά του ΟΤΕ δεν ξέρω, θέλει διερεύνηση.

Εγώ πάλι λέω να μην επεκταθούμε σε τίποτα. Η ερώτηση ήταν θεωρητική και η απάντηση μου
σαφέστατη: "Ο ISP μπορεί να σου βάλει delay (χωρίς απαραίτητα να έχεις congestion) σε ορισμένα πακέτα που κρίνει σκόπιμο".

Τεχνικά σίγουρα μπορεί. Εαν όμως έχει διαθέσιμο bandwidth δεν βλέπω τον λόγο να το κάνει. Για να έχει άδεια γραμμή; Δεν νομίζω. Αν όμως γεμίζει η γραμμή, τότε σίγουρα κάνει κάποιας μορφής QoS.

ακόμα και στο μισό δευτερόλεπτο, το παλέυεις (να μιλήσεις).

To ξέρω αλλά όπως είπα είναι οριακό. Αν ανέχεσαι να ακούς τον άλλο με καθυστέρηση στον ήχο, μπορεί να πάει και παραπάνω.

[anon]

Το traffic shaping προκαλεί delay όταν ενεργοποιείται
Το voip θέλει max 150ms (one-way) για να παίξει χωρίς καθυστέρηση

συμφωνώ και το έχω δεί στην πράξη γιατί έχουμε βάλει voip εδώ, και ενδοεταιρικό και μέσω internet.

To ftp (control & data) είναι στο 99% των περιπτώσεων tcp

είχα στο μυαλό μου το tftp...

[trojy]

Trojy δε νομίζω πως πηγαίνει τόσο μακριά το πράμα. Αν προσέξεις άλλοι στο forum το έχουν το πρόβλημα κι άλλοι δεν το έχουν. Οπότε δε μπορούμε να μιλάμε για πολιτική μιας εταιρίας ή ενός οργανισμού.

Νομίζω ότι είναι σημαντικό να εντοπίσουμε το πρόβλημα. Από ότι μου είπε ο τεχνικός της forthnet, 1η φορά έχει γίνει ανάλογο παράπονο. Εξάλλου πριν 3 ημέρες όλα δούλευαν υπέροχα.

Στις προβληματικές συνδέσεις (πίτα dslam) παρατηρείται συνήθως το φαινόμενο αυτό.
Βασικά συμπτώματα
α) μεγάλο ping στο πρώτο hop αν κάνεις tracert οπουδήποτε
β) προβλήματα σε p2p που χρησιμοποιούν πολλές συνδέσεις
γ) max packets/sec που δε ξεπερνούν τα 25 (υπό φυσιολογικές συνθήκες είναι πάνω από 80)

Γνωρίζω περί του θέματος, αλλά νομίζω ότι είναι κάτι διαφορετικό. Στη γραμμή μου δεν γίνεται άλλο traffic πέρα από τα πολλά UDP πακέτα του voip.

Κάνε το εξής:
Πάρε ένα demo από άλλους ISP, και αν με άλλους δεν έχεις πρόβλημα τα φταίει η FORTHney, αλλιώς ο ΟΤΕ. Μπορεί και οι 2 βέβαια.
Αν τελικά το κάνεις, πες μας μετά τα αποτελέσματα.

Είναι κάτι που έχω σκοπό να κάνω.


Για να γίνω περισσότερο καταννοητός... :
-------------------------------------------------------------------
1)
κάνοντας ping στο bbras-ath-02L0.forthnet.gr [194.219.252.144]
Ping statistics for 194.219.252.144:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 48ms, Maximum = 57ms, Average = 53ms
--------------------------------------------------------------------
2) Τρέχω ένα πρόγραμμα που συνδέεται με VOIP
C:\Documents and Settings\TROjY>ping -t 194.219.252.144

Pinging 194.219.252.144 with 32 bytes of data:

Reply from 194.219.252.144: bytes=32 time=52ms TTL=254
Reply from 194.219.252.144: bytes=32 time=62ms TTL=254
Reply from 194.219.252.144: bytes=32 time=68ms TTL=254
Reply from 194.219.252.144: bytes=32 time=569ms TTL=254
Reply from 194.219.252.144: bytes=32 time=1013ms TTL=254
Reply from 194.219.252.144: bytes=32 time=1340ms TTL=254
Reply from 194.219.252.144: bytes=32 time=2098ms TTL=254
Reply from 194.219.252.144: bytes=32 time=3109ms TTL=254
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 194.219.252.144: bytes=32 time=782ms TTL=254
Reply from 194.219.252.144: bytes=32 time=185ms TTL=254
Reply from 194.219.252.144: bytes=32 time=554ms TTL=254
Reply from 194.219.252.144: bytes=32 time=962ms TTL=254
Reply from 194.219.252.144: bytes=32 time=658ms TTL=254
Reply from 194.219.252.144: bytes=32 time=101ms TTL=254
Reply from 194.219.252.144: bytes=32 time=62ms TTL=254
Reply from 194.219.252.144: bytes=32 time=54ms TTL=254
Reply from 194.219.252.144: bytes=32 time=60ms TTL=254
Reply from 194.219.252.144: bytes=32 time=55ms TTL=254

Ping statistics for 194.219.252.144:
Packets: Sent = 39, Received = 18, Lost = 21 (53% loss),
Approximate round trip times in milli-seconds:
Minimum = 52ms, Maximum = 3109ms, Average = 654ms


Όταν έχω ping time out, δεν είναι μόνο για τα ICMP πακέτα του ping, αλλά και για τα tcp/udp. Κοινώς, δεν βλέπω ούτε ιστοσελίδες, ούτε δίκτυο, ούτε τίποτα... όπλο κενό!
Παράλληλα, το outgoing traffic πάει μούρλια..

Ο router μου είναι ένα slackware 10.1 που έπαιζε σε γενικές γραμμές άριστα. Αλλαγή δεν έγινε,
reboot του έκανα κάμποσα και σε όλα τα εμπλεκόμενα μέρη.

Εσείς έχετε ανάλογο πρόβλημα? Σε φίλους που ρωτάω από Ηράκλειο Κρήτης, Ναι.
--------------------------------------------------------------------------------------------------------