lsquic running on ultra-slow connections

[psheer-spirent]

I am running an artificial scenario where the packet ping time is over 1000ms in order to simulate a very slow connection.

It seems that lsquic will not complete a small web page download in this situation due to timeouts.

I have tried to increase various timeout values in the headers, as well as to alter alarm expiry times where I can find them, but there seems to be no simple set of code changes that resolves this problem.

Actually, this is quite important for us for Valgrind testing of our application:
Valgrind makes our app 50X slower, effectively making it as slow as simulating a network with a very long ping time.

Do yourselves have an suggestions?
Is there a proper place to configure lsquic for very-very-slow networks, and is this a supported configuration?

Thank you

[litespeedtech]

We use Address Sanitizer instead of Valgrind most time, much lower performance penalty.

[psheer-spirent]

We use Address Sanitizer instead of Valgrind most time, much lower performance penalty.

Thanks for your response.

Although -fsanitize=address (and clang -fsanitize=memory) are very useful, these do not reliably detect use of uninitialized data.

Internally, do you do testing on very-high latency connections to see that transactions still complete?

I have not made much progress to understand why the new connection times-out, but it looks like lsquic_mini_conn_ietf.h:typedef uint64_t packno_set_t; is not of sufficient size, and perhaps needs to be extended to 128 bits or more.

I am just inferring due to our server is hitting this line:

lsquic_mini_conn_ietf.c: LSQ_DEBUG("ran out of outgoing packet numbers, won't allocate packet");

The client side is only trying to establish one connection -- so this seems strange to me.

[dtikhonov]

I was able to transfer data using the perf_client and perf_server with RTT of 10 seconds using high timeout values (try -o handshake_to=16777215 -o idle_timeout=600 for the server).

When I bumped the RTT to 20 seconds, the connection was unsuccessful as it ran into decryption problems. There may be some odd bug lurking there, but I am not sure I want to invest time into tracking this down right now.

Which timeouts are you hitting? Turning up the logging should give you an idea.

packno_set_t is described in the docs:

This bitmask is used to keep track of sent, received, and acknowledged packet numbers. It can support up to 64 packet numbers: 0 through 63. We assume that the server will not need to send more than 64 packets to complete the handshake.

So, if the server does a lot of retransmissions before the handshake is completed, you'd see this.

---

At 10 second RTT, we are already far beyond the normal QUIC expectations. I'd say play with the timeouts.