adsl & packet loss bij grote packets

[justice strike]

Ik heb de afgelopen tijd nogal wat zitten kutten met mijn (demon) adsl verbinding. Ik had voornamelijk last van packet loss bij (ip)packets die 30kb en groter. nu is dat wel wat beter geworden, maar hij vertikt het gewoon op meer dan 50kb per packet te versturen (correct te versturen). Ik heb even nagekeken en bij een chello verbinding gaat het wel vlekkeloos. Ik neem aan dat het over adsl ook goed zou moeten gaan. Immers de ip laag fragmenteerd de packets zodanig dat het over het physieke netwerk kan gaan. Daarbij heb je zelf ook weinig zeggenschap over hoe groot de packet worden die je over ip stuurt (dat bepaalt de tcp connectie).

afijn ik ben dus van mening dat ip packetjes tot het maximum goed moeten aankomen aan de andere kan. Echter zoals ik eerder vertelt heb werkt het absoluut niet. Nu heb ik dus iemand even laten testen op een andere adsl verbinding (bij een andere provider) en die kan daarook geen packetjes versturen die meer dan 50kb zijn. Is dit inherent aan adsl? lijkt me niet. zoals ik eerder verteld heb heb je weinig controle over de ip packet grootte die de tcp laag naar ip verstuurd. Daarbij is het vreemd dat het alleen bij 50kb en groter gebeurt aangezien adsl packets per 1500b? verstuurd en dus elk packetje wat groter is dan 1500 per definitie gefragmenteerd moet worden (dat merk je ook als je de don't fragment flag aan zet in ping)

wat is jullie mening hierover?


commando:
ping -t -l 65500 demon.nl

p.s. de site waarop getest wordt kan grote ping packages aan, chello verbinding heeft namelijk wel sucessvol kunnen pingen ernaar. verder hebben we de timeout voor de adsl verbindingen verhoogt naar 2 seconde (wat een eeuwigheid is) dus dat zou ook het probleem niet moeten zijn.

p.s.2 yes gechecked. er zijn wat mensen die vooral met ftp upload veel problemen claimen te hebben. aangezien de packet loss bij bestanden groter dan 50kb bijna 100% is wat ervoor zorgt dat de connectie vrijwel altijd verloren gaat. Dit ligt er natuurlijk ook aan welke ftp implementatie gebruikt wordt. verder is er gewoon heel weinig over te vinden.


p.s.3 waarom grotere packets versturen? omdat het
1. minder overhead heeft, je kan namelijk meer data in 1 tcp packet stoppen.
2. je hebt niet echt zeggenschap over hoe de tcp laag de packets opdeelt. dus het kan voorkomen dat er packets van 50k of meer gestuurd worden, hoe wordt dat dan opgelost?

[ Voor 17% gewijzigd door justice strike op 21-02-2005 23:57 ]

[JvS]

Nou hier werkt het ook niet (adsl van kpn) maar hij doet het vanaf 1500 al niet, 1000 doet-ie wel.

Maareh, waarom wil je dat weten? Uit een principe dat pakketen altijd aan moeten komen? Heb je daar last van dan?

[justice strike]

yes ik heb er last van. niet alleen dat maar je ip laag zou gewoon onafhankelijk van het medium moeten werken, het moet gewoon werken. Het is de vraag waarom hij het bij jouw al niet doet bij 1500. maar dat zou kunnen komen omdat je je ip packeten niet laat fragmenteren en dan ook problemen krijg met het versturen over adsl (mtu van 1500 bytes dus het is wel te verklaren) maar waarom 40kb wel en groter dan 50kb niet?

[ Voor 3% gewijzigd door justice strike op 21-02-2005 23:59 ]

[justice strike]

ok eindelijk mijn nieuwe modem gekregen (moest de oude omruilen om zeker te zijn dat het niet aan de modem lag)

heb nu dus een zyxel prestige 650 (eerst had ik een copperjet 823)

maar de resultaten van deze modem zijn nog slechter. met pingtijden van 4000 waar deze op de 823 1000 waren (grote packetten dus opzich mag de ping wel hoog zijn, maar niet 4 keer zoveel als wat het eerst was)

verder zie ik in de terminal naar mijn zyxel dat wel dat alle data tot 53000 bytes de lijn opgegooit worden. maar zelfs op die packet grootte krijg ik geen of weinig replies (grote packet loss dus)

iemand ideeen?

[EricJH]

Waarom wil je zulke grote pakketgroottes? Dat is een vraag uit nieuwsgierigheid.

Als dat problemen oplevert waarom maak je de Receive Window grootte (RWIN) niet groter? Ergens tussen 32k en 64k waarbij het een even veelvoud is van (MTU-40).

[justice strike]

het netwerk moet de maximum tcp packet size ondersteunen. (het werkt zelfs op een chello verbinding) tcp is een laag hoger dan ip. Dus de tcp packet size moet onafhankelijk zijn van het verbindings type. het feit dat het niet werkt duidt erop dat er iets mis is. immers waarom werkt hij wel bij 50k en niet bij 53 k.

er gaat dus waarschijnlijk 53000/1500 (packet grootte van adsl) wat betekent dat 1 op de 35 packeten verloren gaat. Dat is veel.

verder kan ik me geen andere reden bedenken waarom hij opeens een veel hogere packetloss heeft bij grootte tcp packets.

waarom wil ik dit opgelost hebben? omdat je zelf niet echt veel te zeggen hebt over de groote van de tcp packets. (ik bedoel weet iemand waar je dat kan instellen? ik kan alleen de mtu ergens instellen maar dat is alleen relevant voor de ip packets)

grotere packets hebben overigens minder overhead dan kleinere packets, dus effectief heb je meer bandbreedte en natuurlijk is het een heel erg vreemd verschijnsel dat er opeens veel meer packet loss is bij grootte packetten.


(overigens heeft dit euvel waarschijnlijk niets te maken met de instellingen van de tcp/ip stack... aangezien het met een andere computer over een chello verbinding wel werkt. ook een standaard install)

[ Voor 11% gewijzigd door justice strike op 25-02-2005 14:22 ]

[leuk_he]

Als je bij ping geen -f vlag opgeeft gaat het in kleine stukjes dus dat is je probeem niet. Bij zo'n grote paketten zul je wel de timeout iets hoger moetn zetten (-w optie) anders lukt het wellicht niet binnen 4 seconden een response te geven (wat de timeout zou verklaren.)

maar zolang je geen -f (do not fragment) valg opgeeft ben je iets heel ander aan het testen. er er ook ergen een (oud) topic wat is je MTU. zoek dat ook eens op.

[justice strike]

hij moet ook wel gefragmented worden, dus dat is ook niet mijn probleem. Uiteraard moeten tcp packets gefragmented worden omdat een 64k packet niet over ethernet heen kan (misschien gigabit ethernet)

de mtu is standaard voor windows, 1500 als ik me niet vergis. En de response tijd maakt niets uit, ik krijg helemaal niets terug van de de server. (kan ik zien in de telnet sessie naar de adsl modem. je ziet wel de packet eruit gaan, maar er komt niets terug). verder kan ik je ook vertellen dat de packet size daadwerkelijk ook ondersteund wordt door de server die ik aan het pingen ben aangezien hij het wel doet met een chello verbinding (sommige gooien te grote ping packages gewoon weg).

ik heb net even gekeken maar ik zie de mtu settings niet op de plaats waar die zou moeten staan en kan dus niet met zekerheid zeggen wat deze is. maar ik de dsl verbinding met meerdere pc's geprobeerd, met en zonder router ertussen. dus het is wel de standaard waarde van windows.

[ Voor 17% gewijzigd door justice strike op 25-02-2005 14:45 ]

[Verwijderd]

Je haalt volgens mij een aantal zaken door de war.

Wanneer een applicatie een grote hoeveelheid data wil laten versturen over een TCP verbinding, zal TCP deze data opdelen in meerdere TCP packets aan de hand van de MTU MSS. Zoals je zelf aan aangeeft, fragmenteert de IP-laag (iig. bij gebruik van IPv4; IPv6 doet dit niet meer) de TCP packets nog verder wanneer blijkt dat een IP-packet te groot is voor het fysieke medium waarover het de volgende hop verstuurd moet worden.

Als je een groot TCP packet verstuurt, zou dit dus inderdaad altijd aan moeten komen omdat de uiteindelijke grootte van de datalinklaag frames op de fysieke lijn past door het toepassen van fragmentatie. Door het versturen van grote TCP packets kun je in theorie inderdaad efficienter gebruikmaken van je bandbreedte, omdat er relatief gezien minder bandbreedte besteed wordt aan het versturen van TCP headers. Echter, wanneer jouw grote TCP packet door de IP-laag wordt opgedeeld in meerdere fragmenten (wat bij packet groottes van 50 kb zeker zal gebeuren, aangezien de Ethernet standaard een maximale datalinklaag frame grootte heeft van 1518 bytes) wordt de inhoud van 1 TCP packet dus uitgesmeerd over meerdere IP-packets. Wanneer een van deze IP-packets nu bij een volle wachtrij aankomt op een router, of een collision krijgt op de datalinklaag of om andere reden niet aankomt, zorgt dat ervoor dat je gehele TCP packet van 50 kb niet aankomt. Dit zal dan door de TCP-timeout of triple-acknowledge opgemerkt worden, waardoor je TCP packet van 50 kb weer in zijn geheel opnieuw verstuurd moet worden. Wanneer je echter kleine TCP packets verstuurt, hoeft er veel minder data opnieuw te worden verzonden bij het verlies van een IP-packet of datalinklaag frame. Hierdoor hoeft het dus zeker niet zo te zijn dat een grote TCP-packet size een efficienter gebruik van je bandbreedte oplevert, zeker niet wanneer jouw dataverkeer langs drukke routers moet of over relatief lossy links verstuurd wordt.

Dat brengt me bij het punt van de ping time-out. In je post suggereer je dat je met het ping commando kunt testen hoe jouw verbinding omgaat met grote TCP packets. Het ping commando is echter een onderdeel van het ICMP protocol, wat GEEN gebruik maakt van de transportlaag ( http://corky.net/2600/data-networks/icmp.shtml ). Het is als het ware "naast" IP op de netwerklaag geimplementeerd. Je kunt met ping dus niet meten hoe jouw verbinding omgaat met grote TCP packets. Je kunt voor jezelf heel makkelijk nagaan dat ping niet over TCP werkt. TCP biedt namelijk een reliable dienst, die garandeert dat al je packets (uiteindelijk) altijd aankomen. Het feit dat je als ping-uitvoer een "Time-out bij opdracht" krijgt oftewel packet loss, geeft dus al aan dat er geen gebruik gemaakt kan zijn van TCP.

Met bovenstaande uitleg in het achterhoofd is het dus heel logisch dat grote pakketten meer packet loss opleveren dan kleine packets. Dan rest nog de vraag waarom je Chello verbinding wel kan pingen met zulke grote packets. Wellicht dat de routers die gebruikt worden om via je Chello verbinding te pingen minder druk zijn dan degene die gebruikt worden voor je ADSL lijn, wat de kans op het moeten weggooien van een packet door volzittende ontvangstbuffers kleiner maakt. Daarnaast is het mogelijk dat de routers die bij je ADSL verbinding gebruikt worden een andere policy hanteren wat betreft ICMP packets, waardoor de stroom aan gefragmenteerde ICMP-echo request berichten die resulteert van het geven van een ping commando met een grote packetsize niet doorgelaten wordt.

[ Voor 1% gewijzigd door Verwijderd op 25-02-2005 16:46 . Reden: MTU -> MSS (bedankt justice_strike) ]

[leuk_he]

justice_strike schreef op vrijdag 25 februari 2005 @ 14:36:
hij moet ook wel gefragmented worden, dus dat is ook niet mijn probleem.

als je gewoon 1000 pakketjes van 1460 bytes stuurt heeft dat een zelfde gevolg als 23 pakketjes van 65000 bytes. Maar je kunt veel nauwkeuriger bepalen hoe vaak het fout gaat. Er zijn ook versies van tracert (niet de standaard windows) waarmee je zou kunnen bepalen bij welke hop je de pakketjes verliest. dan kun je vaststellen of het aan adsl of aan je provider ligt.

Dat bedoelde ik te zeggen. Want zoals je zelf hebt vastgesteld werkt er iets niet maar weet je niet waar het fout gaat.

(of lees de ip/icmp/tcp cursus hierboven van excortitus door)

[ Voor 5% gewijzigd door leuk_he op 25-02-2005 15:21 ]

[justice strike]

Verwijderd schreef op vrijdag 25 februari 2005 @ 15:10:
Je haalt volgens mij een aantal zaken door de war.

Wanneer een applicatie een grote hoeveelheid data wil laten versturen over een TCP verbinding, zal TCP deze data opdelen in meerdere TCP packets aan de hand van de MTU. Zoals je zelf aan aangeeft, fragmenteert de IP-laag (iig. bij gebruik van IPv4; IPv6 doet dit niet meer) de TCP packets nog verder wanneer blijkt dat een IP-packet te groot is voor het fysieke medium waarover het de volgende hop verstuurd moet worden.

mtu is de data size van je ip packet. ik heb het nog even nagezocht omdat ik door dit verhaal even in de war raakte. deze is voor windows standaard 1500 en heeft voor de rest weinig met tcp te maken.
http://m1.mny.co.za/help/...6a07004a5adb?OpenDocument

Als je een groot TCP packet verstuurt, zou dit dus inderdaad altijd aan moeten komen omdat de uiteindelijke grootte van de datalinklaag frames op de fysieke lijn past door het toepassen van fragmentatie. Door het versturen van grote TCP packets kun je in theorie inderdaad efficienter gebruikmaken van je bandbreedte, omdat er relatief gezien minder bandbreedte besteed wordt aan het versturen van TCP headers. Echter, wanneer jouw grote TCP packet door de IP-laag wordt opgedeeld in meerdere fragmenten (wat bij packet groottes van 50 kb zeker zal gebeuren, aangezien de Ethernet standaard een maximale datalinklaag frame grootte heeft van 1518 bytes) wordt de inhoud van 1 TCP packet dus uitgesmeerd over meerdere IP-packets. Wanneer een van deze IP-packets nu bij een volle wachtrij aankomt op een router, of een collision krijgt op de datalinklaag of om andere reden niet aankomt, zorgt dat ervoor dat je gehele TCP packet van 50 kb niet aankomt. Dit zal dan door de TCP-timeout of triple-acknowledge opgemerkt worden, waardoor je TCP packet van 50 kb weer in zijn geheel opnieuw verstuurd moet worden. Wanneer je echter kleine TCP packets verstuurt, hoeft er veel minder data opnieuw te worden verzonden bij het verlies van een IP-packet of datalinklaag frame. Hierdoor hoeft het dus zeker niet zo te zijn dat een grote TCP-packet size een efficienter gebruik van je bandbreedte oplevert, zeker niet wanneer jouw dataverkeer langs drukke routers moet of over relatief lossy links verstuurd wordt.

je moet maar even opzoeken. Maar een packet loss van 1% is normaal, packet loss van 3% over internet is meestal al ernstig veel. normaal zou dus 1 op de 100 packeten verloren mogen gaan. Dat betekent dat je een max data size van 148500 zou kunnen hebben. Dit is al vele malen hoger dan de 65500 die als max van tcp packets geld. het zou dus met gemak moeten kunnen. echter wil bij 65500 bytes geen enkele packet aankomen. en bij 53000 packets slechts 25% (75% packet loss dus) dat is verre van acceptabel

Dat brengt me bij het punt van de ping time-out. In je post suggereer je dat je met het ping commando kunt testen hoe jouw verbinding omgaat met grote TCP packets. Het ping commando is echter een onderdeel van het ICMP protocol, wat GEEN gebruik maakt van de transportlaag ( http://corky.net/2600/data-networks/icmp.shtml ). Het is als het ware "naast" IP op de netwerklaag geimplementeerd. Je kunt met ping dus niet meten hoe jouw verbinding omgaat met grote TCP packets. Je kunt voor jezelf heel makkelijk nagaan dat ping niet over TCP werkt. TCP biedt namelijk een reliable dienst, die garandeert dat al je packets (uiteindelijk) altijd aankomen. Het feit dat je als ping-uitvoer een "Time-out bij opdracht" krijgt oftewel packet loss, geeft dus al aan dat er geen gebruik gemaakt kan zijn van TCP.

tcp is op een best effort basis. Het zal proberen te resenden oid maar als het echt niet lukt dat kapt hij er ook mee. ICMP is altijd een betere manier om reliability te testen. Als je namelijk 75% packet loss hebt. Dat kan je er gif op innemen dat de tcp connectie er ook mee kapt.

Met bovenstaande uitleg in het achterhoofd is het dus heel logisch dat grote pakketten meer packet loss opleveren dan kleine packets. Dan rest nog de vraag waarom je Chello verbinding wel kan pingen met zulke grote packets. Wellicht dat de routers die gebruikt worden om via je Chello verbinding te pingen minder druk zijn dan degene die gebruikt worden voor je ADSL lijn, wat de kans op het moeten weggooien van een packet door volzittende ontvangstbuffers kleiner maakt. Daarnaast is het mogelijk dat de routers die bij je ADSL verbinding gebruikt worden een andere policy hanteren wat betreft ICMP packets, waardoor de stroom aan gefragmenteerde ICMP-echo request berichten die resulteert van het geven van een ping commando met een grote packetsize niet doorgelaten wordt.

het is logisch dat de packet loss hoger zou zijn, maar dat maakt het niet acceptabel.

[leuk_he]

justice_strike schreef op vrijdag 25 februari 2005 @ 15:58:
[...]
je moet maar even opzoeken. Maar een packet loss van 1% is normaal, packet loss van 3% over internet is meestal al ernstig veel. normaal zou dus 1 op de 100 packeten verloren mogen gaan. Dat betekent dat je een max data size van 148500 zou kunnen hebben. Dit is al vele malen hoger dan de 65500 die als max van tcp packets geld. het zou dus met gemak moeten kunnen. echter wil bij 65500 bytes geen enkele packet aankomen. en bij 53000 packets slechts 25% (75% packet loss dus) dat is verre van acceptabel

Waarbij (nogmaals) het veel nauwkeuriger vast te stellen is door veel pakketjes van 1500 bytes te sturen en dan te kijken wat je pakketloss is. En wellicht met tracert te bepalen waar.

Maar... waar haal je die 1% en 3% vandaan. ik kan ze zo snel niet vinden.

[Verwijderd]

justice_strike schreef op vrijdag 25 februari 2005 @ 15:58:
mtu is de data size van je ip packet. ik heb het nog even nagezocht omdat ik door dit verhaal even in de war raakte. deze is voor windows standaard 1500 en heeft voor de rest weinig met tcp te maken.
http://m1.mny.co.za/help/...6a07004a5adb?OpenDocument

Klopt, dat had MSS moeten zijn. Maar dat maakt voor de rest van het betoog niet uit.

je moet maar even opzoeken. Maar een packet loss van 1% is normaal, packet loss van 3% over internet is meestal al ernstig veel. normaal zou dus 1 op de 100 packeten verloren mogen gaan. Dat betekent dat je een max data size van 148500 zou kunnen hebben. Dit is al vele malen hoger dan de 65500 die als max van tcp packets geld. het zou dus met gemak moeten kunnen. echter wil bij 65500 bytes geen enkele packet aankomen. en bij 53000 packets slechts 25% (75% packet loss dus) dat is verre van acceptabel

Ten eerste: hoe kom je aan een max data size van 148500? 148500 = 99 * 1500 maar dan begrijp ik de verantwoording voor die berekening nog niet.

Verder: stel je verbinding heeft een packet loss van 1% op de IP-laag (ik ga er even vanuit dat je 1% slaat op IP-packets). Wanneer je nu een ICMP bericht stuurt dat niet gefragmenteerd wordt, zal de packetloss voor die packets een indicatie zijn voor de totale packetloss over je verbinding. Als je cijfers kloppen zou dat dus ongeveer 1% van de totale packets mogen zijn. Dat betekent echter niet dat als je ICMP packets stuurt die gefragmenteerd moeten worden, dat daar dan ook 1% van aankomt. Wanneer er namelijk 1 van de fragmenten kwijt raakt, resulteert dat in een packet loss voor het totale ICMP bericht. Stel je maakt een ICMP bericht dat in 2 packets moet worden opgesplitst om over internet te worden verzonden. Dan betekent dat dus dat voor 50 van die ICMP packets, er 100 fragmenten worden verzonden. Gemiddeld raakt er daarvan dan 1 kwijt. Dat heeft dan tot gevolg dat het oorspronkelijke ICMP bericht waar dat fragment een deel van uitmaakt kwijt raakt. Dan raak je dus 1 van je 50 oorspronkelijke ICMP packets kwijt; dit is dus 2%. In het algemeen is de verwachte packet loss van een ICMP bericht dat in N fragmenten moet worden opgesplitst, dus N * 1 %.

En dan moet je hierbij ook nog rekening houden met het feit dat sommige routers tussen jou ADSL modem en de doelhost, misschien een speciale policy hanteren mbt. grote echo-request ICMP packets, waardoor je antwoorden misschien bewust geblokkeerd worden.

tcp is op een best effort basis. Het zal proberen te resenden oid maar als het echt niet lukt dat kapt hij er ook mee. ICMP is altijd een betere manier om reliability te testen. Als je namelijk 75% packet loss hebt. Dat kan je er gif op innemen dat de tcp connectie er ook mee kapt.

Bij 75% packet loss kun je nog rustig een TCP verbinding onderhouden wanneer de packet loss ontstaat door genegeerde packets in doorvoer routers. Doordat de packets dan in de verkeerde volgorde aankomen zullen er meerdere acknowledges voor een al eerder ontvangen packet verstuurd worden. Hierdoor weet de oorspronkelijke verzender, wanneer er 3 acknowledges voor hetzelfde packet nummer zijn ontvangen, dat er een packet is kwijtgeraakt en vrolijk opnieuw begint te versturen. Wanneer er packet loss ontstaat door time-outs doordat packets de verkeerde kant op gerouterd worden is er inderdaad een probleem. Maar dit is allemaal niet echt relevant; waar het om gaat is dat ping geen gebruik maakt van TCP, en je aan de hand van de uitkomsten van ping dus ook niet veel kunt zeggen over het gedrag van je ADSL-lijn voor TCP verbindingen.

[justice strike]

leuk_he schreef op vrijdag 25 februari 2005 @ 16:24:
[...]


Waarbij (nogmaals) het veel nauwkeuriger vast te stellen is door veel pakketjes van 1500 bytes te sturen en dan te kijken wat je pakketloss is. En wellicht met tracert te bepalen waar.

Maar... waar haal je die 1% en 3% vandaan. ik kan ze zo snel niet vinden.

ga ik proberen, maar moet even kijken waar ik die tracert versie van je vandaan kan halen

[justice strike]

Verwijderd schreef op vrijdag 25 februari 2005 @ 17:03:
[...]


Klopt, dat had MSS moeten zijn. Maar dat maakt voor de rest van het betoog niet uit.

dan heb je alsnog een probleem, want er wordt meestal gekeken hoeveel de hosts aankunnen. Dus als allebei de hosts de een tcp connectie willen aangaan zeggen dat ze een packet size van 65500 ondersteunen dan wordt de kleinste van de twee gekozen. In dit geval dus 65500 waardoor de mss dus op 65500 zit en niet lager is. Daarbij ondersteund niet elke tcp/ip stack de MSS. Ik heb zelf een werkende tcp implementatie gemaakt die helemaal geen gebruik maakt van MSS.

Ten eerste: hoe kom je aan een max data size van 148500? 148500 = 99 * 1500 maar dan begrijp ik de verantwoording voor die berekening nog niet.

Verder: stel je verbinding heeft een packet loss van 1% op de IP-laag (ik ga er even vanuit dat je 1% slaat op IP-packets). Wanneer je nu een ICMP bericht stuurt dat niet gefragmenteerd wordt, zal de packetloss voor die packets een indicatie zijn voor de totale packetloss over je verbinding. Als je cijfers kloppen zou dat dus ongeveer 1% van de totale packets mogen zijn. Dat betekent echter niet dat als je ICMP packets stuurt die gefragmenteerd moeten worden, dat daar dan ook 1% van aankomt. Wanneer er namelijk 1 van de fragmenten kwijt raakt, resulteert dat in een packet loss voor het totale ICMP bericht. Stel je maakt een ICMP bericht dat in 2 packets moet worden opgesplitst om over internet te worden verzonden. Dan betekent dat dus dat voor 50 van die ICMP packets, er 100 fragmenten worden verzonden. Gemiddeld raakt er daarvan dan 1 kwijt. Dat heeft dan tot gevolg dat het oorspronkelijke ICMP bericht waar dat fragment een deel van uitmaakt kwijt raakt. Dan raak je dus 1 van je 50 oorspronkelijke ICMP packets kwijt; dit is dus 2%. In het algemeen is de verwachte packet loss van een ICMP bericht dat in N fragmenten moet worden opgesplitst, dus N * 1 %.

En dan moet je hierbij ook nog rekening houden met het feit dat sommige routers tussen jou ADSL modem en de doelhost, misschien een speciale policy hanteren mbt. grote echo-request ICMP packets, waardoor je antwoorden misschien bewust geblokkeerd worden.

als bij 65500 bytes elk packetje verloren gaat. dan kan je ervan uitgaan dat de packet loss minstens 1 op de 43 is. MINSTENS omdat de packet ook verloren gaat als er meer dan 1 per 43 verloren gaat.

dit is dus ALTIJD het geval.

nu is het zo dat bij 53000 er 75% packet loss is. Dit kan je dus niet ophangen aan policies van routers. Een routering van een packetje (zeker binnen het netwerk van je isp) is redelijk statisch. Dus of alles zou geblocked moeten worden, of alles er door moeten gaan. Je kunt er dus vanuit gaan dat er iets mis is met de verbinding en niet met de policies van eventuele routers die er tussen hangen. verder geeft dat dus aan dat de packet loss niet 1 op de 43 is maar 0.75 op de 43 is, wederom minstens!! want de packet loss kan ook hoger uitvallen.

Bij 75% packet loss kun je nog rustig een TCP verbinding onderhouden wanneer de packet loss ontstaat door genegeerde packets in doorvoer routers. Doordat de packets dan in de verkeerde volgorde aankomen zullen er meerdere acknowledges voor een al eerder ontvangen packet verstuurd worden. Hierdoor weet de oorspronkelijke verzender, wanneer er 3 acknowledges voor hetzelfde packet nummer zijn ontvangen, dat er een packet is kwijtgeraakt en vrolijk opnieuw begint te versturen. Wanneer er packet loss ontstaat door time-outs doordat packets de verkeerde kant op gerouterd worden is er inderdaad een probleem. Maar dit is allemaal niet echt relevant; waar het om gaat is dat ping geen gebruik maakt van TCP, en je aan de hand van de uitkomsten van ping dus ook niet veel kunt zeggen over het gedrag van je ADSL-lijn voor TCP verbindingen.

dat is afhankelijk van de implementatie. De rfc laat je daar volledig vrij in. als jij iedere keer een packet stuurt en je krijg geen ack voor het packet, dan kan je zelf beslissen hoe je dat afhandeld. Zoals ik al zei de tcp is een best effort protocol. Je kunt geen gegarandeerde communicatie over een unreliable netwerk hebben.


verder wil ik nog even kwijt dat pingen zo ongeveer de beste manier is om de reliability van je connectie te testen. Als je een packet loss hebt van 75% oid dan weet je ook zeker dat je tcp connectie niet heel denderent zal zijn. tuurlijk zal hij retransmissions doen en dergelijke, maar de connectie zelf wordt ook effectief dus langzamer.


ondertussen heb ik een test met tracert gedaan de site die ik ping zit 2 routers verder. Helaas kan ik geen goede ping doen op de routers dus veel info kan ik er niet over krijgen.

[ Voor 6% gewijzigd door justice strike op 25-02-2005 20:51 ]

[Brahiewahiewa]

In [rml]Brahiewahiewa in "[ exchange] probleem met smtp connector n..."[/rml] heb ik een sciptje gepost waarmee je de MTU naar een bepaalde host (nu staat er relay.introweb.nl; kun je vervangen door een andere bestemming) kunt meten

[justice strike]

Brahiewahiewa schreef op vrijdag 25 februari 2005 @ 20:50:
In [rml]Brahiewahiewa in "[ exchange] probleem met smtp connector n..."[/rml] heb ik een sciptje gepost waarmee je de MTU naar een bepaalde host (nu staat er relay.introweb.nl; kun je vervangen door een andere bestemming) kunt meten

mtu of mss?

de mss zou automatisch veranderd moeten worden, en de mtu is een vast getal... ik weet eerlijk gezegd niet echt wat ik hiermee moet?!?


trouwens ik ben er nog steeds niet achter hoe ik de mtu moet veranderen

[ Voor 26% gewijzigd door justice strike op 25-02-2005 20:56 ]

[JvS]

Maar als ik alles goed begrijp vind je dus uit principe dat je die pakketjes moet kunnen sturen? Je zei eerder nog dat je er last van had

[justice strike]

yup uitvallende connectie. dat bijvoorbeeld de totale lijn eruit knalt etc.. heb er aardig wat tijd in gestoken en ben tot de conclusie gekomen dat het hier toch aan moet liggen. Natuurlijk is dit een bijverschijnsel van het daadwerkelijke probleem. dat de connectie gewoon slecht is of dat er een slechte router in de kring zit. Maar in principe zou als dit verholpen is ook meteen alle problemen met de uitknallende lijnen verholpen zijn.

dus nu is de vraag hoe kom ik erachter wat het probleem is. An sich denk ik zelf dat het de "last mile" is. maar het zou best een rotte router kunnen zijn.

heb inmiddels al een beetje met de mtu gespeeld. (met behulp van het scriptje) heel vreemde waardes komen er uit. als je het voor de eerste keer draait (mtu 1500) dan wordt er een mtu van 1472 aangeraden. als je de mtu veranderd en het scriptje nog een keer draait dan zegt hij dat je de mtu moet verlagen naar 1444 en zo gaat het door.


trouwens ik heb even nagedacht. het lijkt me stug dat routers een policy hebben voor het aantal packetjes wat je verstuurt (ip dan) aangezien de lijn zelf tot 8mbit zou moeten kunnen ontvangen. het weggooien van packetjes door de router zou juist averechts voor het netwerk werken.

[ Voor 92% gewijzigd door justice strike op 25-02-2005 21:10 ]

[EricJH]

[b]justice_strike schreef op vrijdag 25 februari 2005 @ 20:58:

heb inmiddels al een beetje met de mtu gespeeld. (met behulp van het scriptje) heel vreemde waardes komen er uit. als je het voor de eerste keer draait (mtu 1500) dan wordt er een mtu van 1472 aangeraden. als je de mtu veranderd en het scriptje nog een keer draait dan zegt hij dat je de mtu moet verlagen naar 1444 en zo gaat het door.
.

Die 1472 is goed te verklaren. Als je de MTU gaat bepalen door het toevoegen van de f vlag aan je data dan moet je bij de pakketgrootte altijd de grootte van de header (als ik het mijn goed herinner) optellen.

Dus bij een MTU van 1500 is het grootste pakket waarbij geen fragmentatie optreedt 1500-28 = 1472.

[justice strike]

ja dat snap ik, maar ik gaf alleen aan dat programmatje niet werkt

[JvS]

justice_strike schreef op vrijdag 25 februari 2005 @ 20:58:
yup uitvallende connectie. dat bijvoorbeeld de totale lijn eruit knalt etc.. heb er aardig wat tijd in gestoken en ben tot de conclusie gekomen dat het hier toch aan moet liggen. Natuurlijk is dit een bijverschijnsel van het daadwerkelijke probleem.

Maar (misschien ben ik heel irritant hoor ), hoe ben je dan tot die conclusie gekomen? Elke (rete stabiele) adsl verbinding heeft dit sypmtoon. Hoe kom je er dan bij dat dit juist bij jou de oorzaak is voor een instabiele verbinding?

Zomaar nieuwschierigheid hoor .

[justice strike]

blijkbaar heeft niet elke adsl verbinding dit. daarbij trained hij ook niet op de hoogste waarde wat ikzelf best vreemd vind. maar dat is een probleem ansich.

maar ik vind het opzich heel vreemd ansich. Want zoals ik al zei als het aan de verbinding ligt dan zou het niet verklaren waarom er een packet loss van 41% is en niet een packet loss van 100 % en waarom de packet loss veranderd naarmate de waarde hoger wordt. Want het probleem dat jij hebt (1500 doet hij het niet) is wel degelijk een andere dan wat er bij mij gebeurt. Ook omdat adsl van kpn via vpn werkt (als ik me niet vergis) maar ook omdat je totaal geen replies binnen krijgt. Ik daarentegen krijg wel pakketen binnen maar met een variabel hoge loss.

Dit geeft dus aan dat het niet een adsl inherent iets is maar iets anders.

[ Voor 81% gewijzigd door justice strike op 25-02-2005 22:36 ]