Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Haperende en Krakende Telefonie
178 views
Skip to first unread message
Ivan Dil
Jul 8, 2014, 8:17:10 AM7/8/14
to
Al enige tijd hebben we problemen met telefonie, de andere persoon aan
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
op een laptop(MacBook) was een update gaande, een vrij grote, toen er
gelijktijdig een binnenkomend gesprek kwam. Het gesprek was niet
mogelijk, ik heb toen ingelogd in de fritzbox om de belasting te
bekijken, zie
http://i.imgur.com/Gyv7VVo.png
Waarom een updatende MacBook ook een groot deel van de uitgaande
bandbreedte gebruikt weet ik niet. De data wordt door de fritzbox ook
als realtime aangemerkt, wat ik vreemd vind. Ik heb bij prioritization
"Internet Telephony" als Real-time application(high priority) staan, en
mijn server als Background application(low priority).
http://i.imgur.com/cu92Eks.png
Ik weet niet of XS4ALL Telefonie onder deze "Internet Telephony"
prioritazion valt of deze is voor SIP devices in het netwerk. Ik vraag
me dit af door het probleem dat ontstaat als er veel uitgaande
bandbreedte utilization is. Telefonie zou dan de hoogste prioriteit
horen te hebben.
"Normaal" ziet het bandbreedte gebruik er tijdens een goed en duidelijk
werkende telefonie er zo uit,
http://i.imgur.com/X53e4c6.png
Deze verschilt niet bijzonder veel van er als er geen telefoon gesprek
plaats vindt en er alleen traffic is van mijn server,
http://i.imgur.com/ZI3D4kV.png
Ik weet niet hoe dit probleem op te lossen is, zou ik nog iets kunnen
met de fritzbox prioritation, of iets anders.
Iemand een idee?
PS: Ik heb hierover al eens contact gehad met de helpdesk, deze gaf als
oplossing up te graden qua abbo. Dit zag ik niet als oplossing omdat dan
de uitgaande bandbreedte door andere devices in het netwerk ook meer
gebruikt wordt. Mijn inziens gaat het fout met het toekennen
van de prioriteit van de traffic. Ook is het zo dat telefonie niet veel
bandbreedte gebruikt. Ze hebben toen wel onze lijn omgezet
van ADSL > VDSL, wat in het begin een instabiele lijn opleverde, nu geen
problemen meer. Qua telefonie maakt ADSL, dan wel VDSL niet uit.
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
op een laptop(MacBook) was een update gaande, een vrij grote, toen er
gelijktijdig een binnenkomend gesprek kwam. Het gesprek was niet
mogelijk, ik heb toen ingelogd in de fritzbox om de belasting te
bekijken, zie
http://i.imgur.com/Gyv7VVo.png
Waarom een updatende MacBook ook een groot deel van de uitgaande
bandbreedte gebruikt weet ik niet. De data wordt door de fritzbox ook
als realtime aangemerkt, wat ik vreemd vind. Ik heb bij prioritization
"Internet Telephony" als Real-time application(high priority) staan, en
mijn server als Background application(low priority).
http://i.imgur.com/cu92Eks.png
Ik weet niet of XS4ALL Telefonie onder deze "Internet Telephony"
prioritazion valt of deze is voor SIP devices in het netwerk. Ik vraag
me dit af door het probleem dat ontstaat als er veel uitgaande
bandbreedte utilization is. Telefonie zou dan de hoogste prioriteit
horen te hebben.
"Normaal" ziet het bandbreedte gebruik er tijdens een goed en duidelijk
werkende telefonie er zo uit,
http://i.imgur.com/X53e4c6.png
Deze verschilt niet bijzonder veel van er als er geen telefoon gesprek
plaats vindt en er alleen traffic is van mijn server,
http://i.imgur.com/ZI3D4kV.png
Ik weet niet hoe dit probleem op te lossen is, zou ik nog iets kunnen
met de fritzbox prioritation, of iets anders.
Iemand een idee?
PS: Ik heb hierover al eens contact gehad met de helpdesk, deze gaf als
oplossing up te graden qua abbo. Dit zag ik niet als oplossing omdat dan
de uitgaande bandbreedte door andere devices in het netwerk ook meer
gebruikt wordt. Mijn inziens gaat het fout met het toekennen
van de prioriteit van de traffic. Ook is het zo dat telefonie niet veel
bandbreedte gebruikt. Ze hebben toen wel onze lijn omgezet
van ADSL > VDSL, wat in het begin een instabiele lijn opleverde, nu geen
problemen meer. Qua telefonie maakt ADSL, dan wel VDSL niet uit.
Rob
Jul 8, 2014, 9:57:34 AM7/8/14
to
Ivan Dil <inv...@invalid.invalid> wrote:
> Al enige tijd hebben we problemen met telefonie, de andere persoon aan
> de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
> kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
> een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
> Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
> was. Dit "bleek" te kloppen, na het aantal TCP connections en de
> bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
> kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
> verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
> Al enige tijd hebben we problemen met telefonie, de andere persoon aan
> de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
> kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
> een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
> Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
> was. Dit "bleek" te kloppen, na het aantal TCP connections en de
> bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
> kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
> verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
nu mee komt.
De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
maar niet voor telefonie.
Er zijn allerlei "oplossingen" voor, maar het blijft lapwerk.
Wel moet ik zeggen dat het sinds ik door XS4ALL op een nieuwe access
router overgezet ben, voor mij veel beter werkt. Ik weet niet of
iedereen al overgezet is en/of dat er toch nog verschillende modellen
of configuraties in gebruik zijn, maar sinds deze wijziging hebben
realtime zaken (VoIP enzo) veel minder last van volgeplempte TCP
sessies (downloads). Ik schat in dat er nu "Fair queueing" gedaan
wordt. (dat betekent dat als er meerdere parallelle datastromen zijn,
de router om en om van iedere stroom een pakketje doorstuurt ipv dat
ze doorgestuurd worden in volgorde van arriveren)
Ivan Dil
Jul 8, 2014, 2:47:52 PM7/8/14
to
alleen niet of dat mogelijk is en of dat een oplossing is.
Miquel van Smoorenburg
Jul 8, 2014, 3:12:12 PM7/8/14
to
In article <slrnlrnu6e...@xs8.xs4all.nl>,
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
Mike.
Rob <nom...@example.com> wrote:
>Ivan Dil <inv...@invalid.invalid> wrote:
>> Al enige tijd hebben we problemen met telefonie, de andere persoon aan
>> de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
>> kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
>> een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
>> Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
>> was. Dit "bleek" te kloppen, na het aantal TCP connections en de
>> bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
>> kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
>> verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
>
>Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
>gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
>heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
>internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
>nu mee komt.
>
>De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
>bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
>maar niet voor telefonie.
Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
>Ivan Dil <inv...@invalid.invalid> wrote:
>> Al enige tijd hebben we problemen met telefonie, de andere persoon aan
>> de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
>> kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
>> een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
>> Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
>> was. Dit "bleek" te kloppen, na het aantal TCP connections en de
>> bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
>> kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
>> verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
>
>Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
>gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
>heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
>internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
>nu mee komt.
>
>De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
>bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
>maar niet voor telefonie.
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
Mike.
Rob
Jul 8, 2014, 3:39:17 PM7/8/14
to
dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
op dezelfde connectie. Ook het probleem met verkeer naar buiten is er
dan niet.
> Waar OP het hier over heeft is dat het gaat haperen als hij
> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
verkeer bij horen lijkt me.
Arwin Vosselman
Jul 8, 2014, 3:53:41 PM7/8/14
to
On 08 Jul 2014 19:39:17 GMT, Rob wrote:
>Volgens mij is het niet gescheiden op de manier waarop andere providers
>dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
>van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
>van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
>op dezelfde connectie. Ook het probleem met verkeer naar buiten is er
>dan niet.
VoDSL, <http://nl.wikipedia.org/wiki/VoDSL>.
>Volgens mij is het niet gescheiden op de manier waarop andere providers
>dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
>van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
>van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
>op dezelfde connectie. Ook het probleem met verkeer naar buiten is er
>dan niet.
--
Arwin.
Ivan Dil
Jul 8, 2014, 4:29:49 PM7/8/14
to
On 2014-07-08, Rob <nom...@example.com> wrote:
> Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> In article <slrnlrnu6e...@xs8.xs4all.nl>,
>> Rob <nom...@example.com> wrote:
>>>Ivan Dil <inv...@invalid.invalid> wrote:
[...]
>> In article <slrnlrnu6e...@xs8.xs4all.nl>,
>> Rob <nom...@example.com> wrote:
>>>Ivan Dil <inv...@invalid.invalid> wrote:
>> Waar OP het hier over heeft is dat het gaat haperen als hij
>> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
>> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
>> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
>
> Ik las dat het fout ging toen er een Macbook een update ging doen en
> ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
> verkeer bij horen lijkt me.
een MacBook zoveel upstream traffic genereert bij een update is mij een
raadsel.
https://i.imgur.com/Gyv7VVo.png
BTW, de binnenkomende spraak (downstream) is altijd glashelder.
Miquel van Smoorenburg
Jul 8, 2014, 5:11:33 PM7/8/14
to
In article <slrnlroi75...@xs8.xs4all.nl>,
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.
>Ook het probleem met verkeer naar buiten is er
>dan niet.
Naar buiten geldt exact hetzelfde, als het over dezelfde
lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
net is begonnen met versturen- daar moet je helaas op wachten.
Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.
>> Waar OP het hier over heeft is dat het gaat haperen als hij
>> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
>> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
>> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
>
>Ik las dat het fout ging toen er een Macbook een update ging doen en
>ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
>verkeer bij horen lijkt me.
Jawel dus, dat is het probleem.
Mike.
Rob <nom...@example.com> wrote:
>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
>> naar de klant toe. Je kan alleen verkeer voorrang geven dat
>> je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
>> niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
>> superbelangrijk, stuur de volgende toch maar daarvoor".
>
>Volgens mij is het niet gescheiden op de manier waarop andere providers
>dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
>van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
>van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
>op dezelfde connectie.
Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
>> naar de klant toe. Je kan alleen verkeer voorrang geven dat
>> je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
>> niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
>> superbelangrijk, stuur de volgende toch maar daarvoor".
>
>Volgens mij is het niet gescheiden op de manier waarop andere providers
>dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
>van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
>van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
>op dezelfde connectie.
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.
>Ook het probleem met verkeer naar buiten is er
>dan niet.
lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
net is begonnen met versturen- daar moet je helaas op wachten.
Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.
>> Waar OP het hier over heeft is dat het gaat haperen als hij
>> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
>> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
>> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
>
>Ik las dat het fout ging toen er een Macbook een update ging doen en
>ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
>verkeer bij horen lijkt me.
Mike.
Ivan Dil
Jul 9, 2014, 3:23:49 AM7/9/14
to
On 2014-07-08, Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
> In article <slrnlrnu6e...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
[...]
> In article <slrnlrnu6e...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
>>gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
>>heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
>>internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
>>nu mee komt.
>>
>>De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
>>bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
>>maar niet voor telefonie.
>
> Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
> naar de klant toe. Je kan alleen verkeer voorrang geven dat
> je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
> niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
> superbelangrijk, stuur de volgende toch maar daarvoor".
>
> Waar OP het hier over heeft is dat het gaat haperen als hij
> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
>
> Mike.
voorrang behoren te krijgen boven het andere verkeer?
http://i.imgur.com/cu92Eks.png
Rob
Jul 9, 2014, 4:04:25 AM7/9/14
to
Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
> In article <slrnlroi75...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>>> Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
>>> naar de klant toe. Je kan alleen verkeer voorrang geven dat
>>> je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
>>> niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
>>> superbelangrijk, stuur de volgende toch maar daarvoor".
>>
>>Volgens mij is het niet gescheiden op de manier waarop andere providers
>>dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
>>van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
>>van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
>>op dezelfde connectie.
>
> Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
> packets eerder over de lijn mogen dan anderen. Of dat nou wordt
> bepaald op basis van VLAN tag, of op basis van source-ip, of
> ergens anders op, dat maakt niet uit.
Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
> In article <slrnlroi75...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>>> Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
>>> naar de klant toe. Je kan alleen verkeer voorrang geven dat
>>> je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
>>> niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
>>> superbelangrijk, stuur de volgende toch maar daarvoor".
>>
>>Volgens mij is het niet gescheiden op de manier waarop andere providers
>>dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
>>van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
>>van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
>>op dezelfde connectie.
>
> Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
> packets eerder over de lijn mogen dan anderen. Of dat nou wordt
> bepaald op basis van VLAN tag, of op basis van source-ip, of
> ergens anders op, dat maakt niet uit.
verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.
Het geven van prioriteit werkt ook alleen maar als het op exact de
juiste plaats gebeurt, en daar is vaak ook nog wel wat op af te dingen
zelfs in een router.
Ook weigert XS4ALL de prioriteit te bepalen aan de hand van het IP
header veld wat daar voor bedoeld is, wat het ook niet beter maakt.
Gelukkig is dat issue opgelost met de nieuwe routers, die zelf al een
goede inschatting maken kennelijk zonder daar naar te kijken.
(of is men uiteindelijk toch "om" gegaan?)
>>Ook het probleem met verkeer naar buiten is er
>>dan niet.
>
> Naar buiten geldt exact hetzelfde, als het over dezelfde
> lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
> de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
> daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
> net is begonnen met versturen- daar moet je helaas op wachten.
> Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.
Miquel van Smoorenburg
Jul 9, 2014, 5:35:57 AM7/9/14
to
In article <slrnlrpts9...@xs8.xs4all.nl>,
maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
welk packet (of cell, meestal) vooraan in de queue komt op
basis van een paar bits in de ATM header. Niks anders dan naar
bits in een VLAN header of een IP header kijken.
>Het geven van prioriteit werkt ook alleen maar als het op exact de
>juiste plaats gebeurt, en daar is vaak ook nog wel wat op af te dingen
>zelfs in een router.
De XS4ALL routers shapen en queuen op de snelheid "op papier", maar
zetten voor voip verkeer ook een 'prio' bitje in de ethernet
header, waardoor verderop in het netwerk (de DSLAM) dat verkeer
ook nog eens in de priority-queue gezet kan worden.
>Ook weigert XS4ALL de prioriteit te bepalen aan de hand van het IP
>header veld wat daar voor bedoeld is, wat het ook niet beter maakt.
Er is bijna niemand die dat buiten een besloten netwerk doet. Dat
is niet "weigeren", dat is "best common practice".
>> Naar buiten geldt exact hetzelfde, als het over dezelfde
>> lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
>> de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
>> daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
>> net is begonnen met versturen- daar moet je helaas op wachten.
>> Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.
>
>Tja maar toch is dat kennelijk niet voldoende, of het werkt bij hem niet.
Door een bug in de fritzbox. (vanaf FritzOS 6.05, geloof ik).
Mike.
Rob <nom...@example.com> wrote:
>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
>> packets eerder over de lijn mogen dan anderen. Of dat nou wordt
>> bepaald op basis van VLAN tag, of op basis van source-ip, of
>> ergens anders op, dat maakt niet uit.
>
>Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
>verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.
Dat snap ik niet. Ook als er ATM gebruikt wordt is er nog steeds
>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
>> packets eerder over de lijn mogen dan anderen. Of dat nou wordt
>> bepaald op basis van VLAN tag, of op basis van source-ip, of
>> ergens anders op, dat maakt niet uit.
>
>Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
>verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.
maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
welk packet (of cell, meestal) vooraan in de queue komt op
basis van een paar bits in de ATM header. Niks anders dan naar
bits in een VLAN header of een IP header kijken.
>Het geven van prioriteit werkt ook alleen maar als het op exact de
>juiste plaats gebeurt, en daar is vaak ook nog wel wat op af te dingen
>zelfs in een router.
zetten voor voip verkeer ook een 'prio' bitje in de ethernet
header, waardoor verderop in het netwerk (de DSLAM) dat verkeer
ook nog eens in de priority-queue gezet kan worden.
>Ook weigert XS4ALL de prioriteit te bepalen aan de hand van het IP
>header veld wat daar voor bedoeld is, wat het ook niet beter maakt.
is niet "weigeren", dat is "best common practice".
>> Naar buiten geldt exact hetzelfde, als het over dezelfde
>> lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
>> de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
>> daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
>> net is begonnen met versturen- daar moet je helaas op wachten.
>> Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.
>
>Tja maar toch is dat kennelijk niet voldoende, of het werkt bij hem niet.
Mike.
Rob
Jul 9, 2014, 5:57:23 AM7/9/14
to
Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
> In article <slrnlrpts9...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>>> Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
>>> packets eerder over de lijn mogen dan anderen. Of dat nou wordt
>>> bepaald op basis van VLAN tag, of op basis van source-ip, of
>>> ergens anders op, dat maakt niet uit.
>>
>>Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
>>verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.
>
> Dat snap ik niet. Ook als er ATM gebruikt wordt is er nog steeds
> maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
> veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
> welk packet (of cell, meestal) vooraan in de queue komt op
> basis van een paar bits in de ATM header. Niks anders dan naar
> bits in een VLAN header of een IP header kijken.
ATM werkt met cellen. Als je een circuit bouwt met een bepaalde gecommitte
> In article <slrnlrpts9...@xs8.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>>Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>>> Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
>>> packets eerder over de lijn mogen dan anderen. Of dat nou wordt
>>> bepaald op basis van VLAN tag, of op basis van source-ip, of
>>> ergens anders op, dat maakt niet uit.
>>
>>Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
>>verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.
>
> Dat snap ik niet. Ook als er ATM gebruikt wordt is er nog steeds
> maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
> veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
> welk packet (of cell, meestal) vooraan in de queue komt op
> basis van een paar bits in de ATM header. Niks anders dan naar
> bits in een VLAN header of een IP header kijken.
snelheid dan zijn er voor dat circuit cellen gereserveerd. Packets hoeven
geen aaneengesloten cellen te zijn. Het verkeer in dat circuit loopt
door op de geconfigureerde snelheid wat er verder ook gebeurt op die
verbinding.
Dat is heel wat anders dan serialiseren van verkeer op een medium
als ethernet. Het kan ongeveer hetzelfde uitwerken, maar dat doet het
alleen als het heel goed geconfigureerd is en overal goed geimplementeerd.
Routerfabrikanten hebben ook andere dingen aan hun hoofd (zoals goed
presteren in naieve throughput testen) en maken dit soort dingen keer
op keer kapot. Nu ook weer kennelijk.
Dat zal met ATM circuits niet zo snel gebeuren.
Miquel van Smoorenburg
Jul 9, 2014, 6:43:17 AM7/9/14
to
In article <slrnlrq4g3...@xs8.xs4all.nl>,
Als ik erover nadenk is dat nog steeds hetzelfde. Goed, je hebt
kleinere cellen dus wat minder jitter, maar waar je het over
hebt is prima op een ander packet-switched netwerk zoals
IP of ethernet te realiseren. En dat gebeurt ook op grote schaal.
Dat moet je ook alleen aan de edge doen, waar de bottleneck is
en waar je niet al te veel queues nodig hebt. In de core moet
je geen QoS/CoS doen. Links daarin horen namelijk gewoon niet
congested te zijn. En bij geen congestie doet QoS/CoS/whatever niks.
>Routerfabrikanten hebben ook andere dingen aan hun hoofd (zoals goed
>presteren in naieve throughput testen) en maken dit soort dingen keer
>op keer kapot. Nu ook weer kennelijk.
>Dat zal met ATM circuits niet zo snel gebeuren.
Ja, omdat niemand meer ATM gebruikt :) Zo is het KPN ATM netwerk
zo'n beetje leeg, en wordt het eind dit jaar definitief uitgezet.
Iedereen en z'n moeder is over op ethernet. Enige ATM wat nog
bestaat is tussen een modem en een DSLAM op ADSL.
Mike.
kleinere cellen dus wat minder jitter, maar waar je het over
hebt is prima op een ander packet-switched netwerk zoals
IP of ethernet te realiseren. En dat gebeurt ook op grote schaal.
Dat moet je ook alleen aan de edge doen, waar de bottleneck is
en waar je niet al te veel queues nodig hebt. In de core moet
je geen QoS/CoS doen. Links daarin horen namelijk gewoon niet
congested te zijn. En bij geen congestie doet QoS/CoS/whatever niks.
>Routerfabrikanten hebben ook andere dingen aan hun hoofd (zoals goed
>presteren in naieve throughput testen) en maken dit soort dingen keer
>op keer kapot. Nu ook weer kennelijk.
>Dat zal met ATM circuits niet zo snel gebeuren.
zo'n beetje leeg, en wordt het eind dit jaar definitief uitgezet.
Iedereen en z'n moeder is over op ethernet. Enige ATM wat nog
bestaat is tussen een modem en een DSLAM op ADSL.
Mike.
Miquel van Smoorenburg
Jul 9, 2014, 6:45:34 AM7/9/14
to
In article <53bcee05$0$2867$e4fe...@news.xs4all.nl>,
in deze thread zei, als het niet werkt is het een bug in
Fritz!OS (vanaf 6.05 denken we). Is in onderzoek bij AVM.
Mike.
Ivan Dil <inv...@invalid.invalid> wrote:
>On 2014-07-08, Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> Waar OP het hier over heeft is dat het gaat haperen als hij
>> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
>> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
>> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
>
>On 2014-07-08, Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>> Waar OP het hier over heeft is dat het gaat haperen als hij
>> verkeer naar buiten stuurt. In dat geval hoort de priorisatie
>> in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
>> vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
>
>Dus zoals het nu configureerd is in de fritzbox zou de XS4ALL VOIP
>voorrang behoren te krijgen boven het andere verkeer?
>
>http://i.imgur.com/cu92Eks.png
Zo zou het out of the box moeten zijn ja. Zoals ik al eerder
>voorrang behoren te krijgen boven het andere verkeer?
>
>http://i.imgur.com/cu92Eks.png
in deze thread zei, als het niet werkt is het een bug in
Fritz!OS (vanaf 6.05 denken we). Is in onderzoek bij AVM.
Mike.
Ivan Dil
Jul 9, 2014, 7:10:51 AM7/9/14
to
0 new messages