Trage snelheid SFTP door veel TCP-retransmissions

[KGTS]

Dag Netweters,

Ik zit met een zeer technisch en specifiek probleem bij SFTP-bestandsoverdrachten naar een NAS bij mij thuis.

Zonder al te veel in detail te gaan:

- vanop een locatie A wordt een SFTP-kanaal opgezet naar locatie B (bij mij thuis, de NAS waarvan sprake).

- de snelheid van de overdracht begint bij mijn maximale downloadsnelheid (~300 Mbps). So far so good.

- binnen de seconde zakt deze snelheid naar ongeveer 15 Mbps en wordt deze niet meer hoger. Not so good...

Ik heb een TCP-dump gedaan en zie aan mijn kant (locatie B dus) gigantisch veel TCP retransmissions en dubbele ACK pakketten.

Ik heb het dan ook maar vanop een andere locatie (zeg maar locatie C) geprobeerd naar locatie B, met hetzelfde probleem. Locatie A en C kunnen naar elkaar wel aan volle snelheid overdragen. Overigens beiden geen Telenet, maar dat maakt denk ik verder weinig uit.

Wat ik zeker weet dat niet het probleem is omdat ik het heb getest:

- Er is op alle locaties voldoende bandbreedte beschikbaar om mijn 300 Mbps te halen op locatie B. Dat lukte 3 weken geleden ook prima van A naar B...

- In mijn LAN werkt het prima, intern haal ik rond de 1 Gbps aan snelheid (limiet switch). Toppie dus!

- de NAS zit bekabeld rechtstreeks achter de modem van Telenet, de nodige poorten enz. geforward. Als netwerk engineer kan ik wel eens iets over het hoofd zien, maar weet ik doorgaans waar ik mee bezig ben. 🙂

- Wanneer ik zelf de verzender ben is er blijkbaar ook geen probleem, de enige limiet is dan mijn upload (20Mbps)... Niet veel testmarge dus, maar het loopt wel vlotter...

- ik heb al geprobeerd bij alle zenderkanten de MTU te verlagen (om packet fragmentation te voorkomen) maar helaas bleek dat niet de oplossing. Ben zelfs tot 1294 MTU gegaan zonder oplossing, maar uiteraard zou een MTU van 1500 gewoon over het hele Telenet netwerk moeten geaccepteerd worden.

Het lijkt dus wel alsof Telenet ergens toch bepaalde pakketten fragmenteert ofzo en dat dit voor vertraging zorgt in aflevering en dus herverzending van pakketten ?

ik kan eventueel een TCP dump toevoegen als dat iemand kan helpen.

Ik vrees dat hier misschien iemand van Telenet Tech mee naar zal moeten kijken, want het is natuurlijk voor 99% van de klanten geen dagelijks probleem. En gelukkig maar. 🙂

Wie ideetjes heeft, ik hoor het graag!

Groeten,

Kenneth

[KGTS]

Ter info bracht iemand mij het fenomeen van "Bufferbloating" ter attentie. Dat zou dan betekenen dat er ergens een te grote buffer wordt bijgehouden (opnieuw vermoed ik: bij Telenet) waardoor de hele overdracht vertraging oploopt.

Als er iemand van Telenet Technische Dienst met kennis van zake dit mee wil nakijken ben ik ter beschikking!

[Sam___D]

Merk je dit ook als je dezelfde connectie tussen je 2 NASsen over een VPN laat lopen?

Ik doe iets gelijkaardig, maar ik gebruik OpenVPN voor de connectie en Synology Hyper Backup voor data transfer (geen idee welk protocol zij gebruiken).

[Sam___D]

Btw, @Suzy , bericht staat in Televisie en hoort thuis onder Internet

[StefaanH]

---

@Sam___D  schreef:

Btw, @Suzy , bericht staat in Televisie en hoort thuis onder Internet

---

Ik weet niet wie het gedaan heeft, maar het is aangepast 😀

[Arnie]

Een packet size van 1500 is wellicht nog te groot. Met behulp van ping kun je de maximum MTU size van de connectie eenvoudig controlleren. Ping met een packet size van (optie -l) 1500 en de do-not-fragment bit set (optie -f), en je zult zien of je pings succesvol zijn of niet. Lukt het niet, test dan met lagere waardes, tot je de max MTU gevonden hebt. In plaats van 8.8.8.8 kun je hier het IP addres van de andere site gebruiken.

ping 8.8.8.8 -f -l 1500

Bovenstaand is de syntax voor ping onder windows.

Onderstaand is een voorbeeld vanaf mijn Win10 virtual machine

C:\Users\user>ping 8.8.8.8 -f -l 1480

Pinging 8.8.8.8 with 1480 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\user>ping 8.8.8.8 -f -l 1470

Pinging 8.8.8.8 with 1470 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1470) time=27ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1470) time=25ms TTL=118

Ping statistics for 8.8.8.8:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 25ms, Maximum = 27ms, Average = 26ms

[KGTS]

Ter info voor wie dit bericht nog zou volgen: Ik ben momenteel in contact met een binnendienst van Telenet die dit met mij mee aan het bekijken is. Het blijkt inderdaad om een probleem te gaan, maar de locatie daarvan is nog niet duidelijk. Ik blijk in elk geval niet de enige klant te zijn die hier last van heeft, want men heeft het probleem weten te reproduceren.

Een modemwissel werd gedacht de oplossing te zijn, maar dat is tot nu toe nog niet gebleken.

We werken er verder aan!

[NofanTasi]

---

We werken er verder aan!

---

@KGTS 

Er kunnen ook bugs in de layer 1 (e.g. ethernet) drivers tussen A en B zitten 

Ik heb een gelijkaardig scenario doorlopen (om uiteindelijk, toen, met de Realtek Semiconductor ethernet driver developers, een fix in de linux driver van, in dat specifiek geval, mijn gateway te bekomen).

Om maar te zeggen: soms is het moeilijk om een vinger in exact correcte richting te wijzen.