What is lag switching?

@h2b2 said in #49:

dude. you're something else.

Don't bother, This guy has a weekly 'Bad Attitude' and 'Superiority Complex' delivery from Amazon

@h2b2 said in #31:

packets are lost and re-transmitted. that's detectable.
It is detectable at the OS level but not at a user process level. Show us any OS that allows in any way detect packet loss from the TCP/IP socket API.

Or even simpler: name a network debugging tool that reasonably reliably shows the packet loss statistics for an individual TCP/IP socket.

Do the above for any OS, doesn't have to be a popular one.

@kalafiorczyk said in #52:

It is detectable at the OS level but not at a user process level.

that's my understanding, too.

Show us any OS that allows in any way detect packet loss from the TCP/IP socket API.

linux.

Or even simpler: name a network debugging tool that reasonably reliably shows the packet loss statistics for an individual TCP/IP socket.

sudo ss -notp

example line

ESTAB 0 0 1.2.3.4:55730 2.3.4.5:443 users:(("chromium-browse",pid=403559,fd=131)) timer:(keepalive,31sec,0)

(keepalive,31sec,0)

the last value, which is 0 in this case, is the number of retransmits.

I've never used ss to look at restransmits until now, so I'm not familiar with it in the least.
It's just my gut feeling that it would be available somewhere. Looks like ss shows it.

It might not be practical to collect and run analysis, i don't know. However, I still think it's possible to detect retransmits.

@kalafiorczyk said in #52:

It is detectable at the OS level but not at a user process level. Show us any OS that allows in any way detect packet loss from the TCP/IP socket API.

Depends on the API. In C, getsockopt() can apparently be used. (It looks like it might not be trivial as I'm not sure it provides an aggregate for the life of the connection, but I haven't ever needed to use it and didn't dig too deep.) I don't know Scala but it's JVM based and I don't believe Java gives access to this through any of its APIs.

There doesn't seem to be a lot of use cases where servers really need to know retransmission statistics.

Or even simpler: name a network debugging tool that reasonably reliably shows the packet loss statistics for an individual TCP/IP socket.

This is generally done OOB with a sniffer like wireshark. (Edit: oh, you said packet loss; I was thinking packet retransmissions - which isn't equivalent though they should be similar. Ping and traceroute are both used to detect packet loss, though using icmp, not on arbitrary sockets.... so back to wireshark.)

Another issue to consider in the VPN lag switching case, though, is the tcp connection is between lichess's server and a server on the VPN side. If the client disconnects vpn briefly, it's not clear if or when that would trigger retransmits from lichess and it probably depends on the VPN protocol in use. E.g. if it's a tcp connection to an OpenVPN server, then retransmits would be handled by the vpn server and never seen by lichess. With UDP it would depend on the implementation. I'm not at all sure about IPsec because I have no hands on experience coding with it.

@h2b2 said in #53:

Oh good! Showing some knowledge of a command line is a start. Now we can argue.

However, I still think it's possible to detect retransmits.

It absolutely is, with a low level enough interface. Best would be to do it from within the server application. Does Scala provide the interface? I think ss just reads and parses /proc/net/tcp but there's nothing stopping lichess from writing their own kernel module for a more performant solution.

But none of this matters.

In the vpn case, they could only detect retransmits to the vpn server. There's no guarantee that those would ever be triggered. And in any case, dropped packets and retransmits are normal. They'd have to keep data about every user's pattern over time to detect if their latency spiked more on their turns* or during faster time controls or against higher rated players or whatever. But they don't need data on retransmits to do that. The retransmits would be reflected in the latency.

• this would be best by far but would likely require a lot more pings and overhead to do with any accuracy.

So can we stop going on about retransmits now?

In the vpn case, they could only detect retransmits to the vpn server.

what are you talking about? tcp is end to end between two processes. The IP layer doesn't matter. Even without a vpn, there could be 30 different IP networks between a pc and the server.

if there was some sort of proxy, like a http proxy, there would be 2 tcp links, pc to proxy, proxy to server.

But you seem to have developed some sort of attitude about it (*you" are something else), so I'm done with ya. I simply don't care if you remain ignorant on the subject or not. As you once said, "whatever Trevor."

please honour this.

@h2b2 said in #56:

what are you talking about? tcp is end to end between two processes. The IP layer doesn't matter. Even without a vpn, there could be 30 different IP networks between a pc and the server.

In the configuration I was talking about, vpn over tcp (e.g. to a openvpn server) retransmits would be handled on the tunnel itself first; so lost packets might never appear lost on connections being tunneled.

So can we stop going on about retransmits now?