-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mlvpn 2.3.1 and packet massive DUP ACK/retransmission #100
Comments
I've done more investigation during the week-end, up to the network cables. |
I'm interested in this - it could explain the issues I'm having too (lower bandwidth than I expect). I have not looked for the dup ack's yet - how are you doing this BTW, using wireshark or something else, it would be nice to replicate your results. Have you played with the re-order buffer? One possibility is that packets are arriving out of order (through one path or the other), and the end points are then re-transmitting. The issue I have is that adding a small reorder buffer doesn't seem to be effective, and a larger one actually seems to have detrimental impact on performance (I ave not yet found a 'sweet spot' in the middle). |
'anecdotally' - seems like my ACK overhead is reduced by increasing the reorder buffer - over the threshold where the buffer is too small, but my bandwidth is slightly negatively impacted....perhaps some sort of throttling effect |
Yes i'm doing it by using wireshark on the windows computers, and tcpdump on the routers. |
Yeah - I've been playing with master (modified a little) |
(English traduction later, but i'm a bit lazy ATM Mes excuses au final pour tout ce bruit. |
Hello,
I am using mlvpn 2.3.1, compiled from this repository
This is a problem that looks like to exist since i've started to use this version (in other words, it's not something new) but i doubted there was a problem since i added a 3rd link to my mlvpn setup.
Like the title says, i have massive dup ack (up to 40 and probably more dup ack for a single packet) and other problems that make my uploaded overused.
The symptom is up to around 1Mb/s tcp ack (and all the related ones) upload for around 10Mb/s download
Server and client config are joined.
mlvpn server+client conf.txt
I've tested eveything that goes thought my mind on each side of the tunnel.
Disabling or enabling the reordering buffer has no effect.
Neither has his size change (tried values 16,64,128,256,512,1024), nor mtu modification (i have no problems accessing websites, current used mtu 1362, on both sides, of course) or modifying/disabling latency_increase values
Neither any combinaison of such tries changed anything
i have even tried to update to mlvpn version master-14e17e8 but with this version i was never able to make the links work, but, if you say it should have worked (with the same config) i will then open a separate issue.
There is no problem with a tcp file transfert from the router to the computer (used SFTP for the test)
I have also tested each of my links outside the mlvpn tunnel, and i have no problems too, the DUP ACK values returns to a really reasonable treshold (like maybe 5% of DUP ACK)
The following tcpdump is from eth0 , where my two dsl modem and my phone is connected.
https://drive.google.com/file/d/0B5omNo0ix2cgek5xRGtvUlJFTms/view?usp=sharing
And this one is from eth1 side, my local network.
https://drive.google.com/file/d/0B5omNo0ix2cgUE5KcVVJaU4xaGM/view?usp=sharing
(files are not accepted by github)
On a side note : I use TAP interface because i relay my IPv6 subnet from my server to my home, something that i wasn't able to do with TUN interface type(disabled at the time to be sure to not add a side problem to this one)
Is there something that i have done terribly wrong, is TAP not designed or technically prevents mlvpn to do reordering, or is it a real bug?
Thanks in advance for the help (et si besoin, si j'ai pas été claire dans mon explication en anglais, je te la réécrirai en français)
PS : the tcpdump file are intended for wireshark rereading.
The text was updated successfully, but these errors were encountered: