Picoquicdemo has a request size limit

[alexj0l]

Hi community,

I'm writing my thesis where I compare multiple QUIC implementations using their perf tool and I need to observe the throughput over 30-50seconds in a network with 10GE links. I've noticed that picoquicdemo does have a limit regarding the request size. Is this right?

I'm running: /home/user/quics/picoquic/picoquicdemo -p 4433 -c /home/user/cert.pem -k /home/user/key.pem on server side and /home/user/quics/picoquic/picoquicdemo -n test -G <cc> -D <server> 4433 /2000000000000 on client side. It always finishes in around 10-15 seconds with the output:

Connection established. Version = 1, I-CID: 49e5911f0b2c0b63, verified: 1
Stream 0 ended after -1119879168 bytes
All done, Closing the connection.
Received a request to close the connection.
The connection is closed!
Out of 1 zero RTT packets, 1 were acked by the server.
Quic Bit was greased by the client.
Quic Bit was greased by the server.
ECN was received (ect0: 2612814, ect1: 0, ce: 0).
ECN was acknowledged (ect0: 18791, ect1: 0, ce: 0).
Received 3175088166 bytes in 16.788163 seconds, 1513.012789 Mbps.
max_data_local: 9528410112
max_stream_data_local: 9525313245
max_data_remote: 1048576
max_stream_data_remote: 0
ack_delay_remote: 1000 ... 1000
max_ack_gap_remote: 64
ack_delay_local: 1000 ... 25000
max_ack_gap_local: 3
max_mtu_sent: 1252
max_mtu_received: 1440
Received ticket from test (h3):
ticket time = 1675592218500, kx = 17, suite = 1301, 118 ticket, 32 secret.
lifetime = 100000, age_add = 4df578da, 0 nonce, 97 ticket, 8 extensions.
ticket extensions: 42(ED: ffffffff),
Client exit with code = 0

Is there a way to send more bytes to be able to inspect the throughput over longer period of time? I also tried to specify more bytes (by adding more zeros) in /20000000000000 and it doesn't help. Thanks in advance.

[huitema]

This is a bug. The second line in the log shows the issue:

Stream 0 ended after -1119879168 bytes

That negative number shows that we have an integer overflow somewhere. It needs to be fixed of course, but I am working on other issues. If you can find it in the code and suggest a fix, that would be great.

Waiting for that, I can suggest a mitigation. The scenario description in the demo program allows for a repetition factor. You could try for example:

./picoquicdemo -n test -G <cc> -D <server> 4433 *200:10000000000

Would instruct the client to "download 1,000,000,000 bytes 200 times", starting the second download after the first finishes, etc.

If the gap between downloads is a problem, you may also want to try:

./picoquicdemo -n test -G <cc> -D <server> 4433 *200:-:10000000000

The hyphen in the second position parameter means "start the download immediately without waiting for the previous one to finish". That should result in processing 200 1GB downloads in parallel, without gaps.

[alexj0l]

Thank you very much!

[huitema]

There is an issue in demo_server_parse_path() in demoserver.c. The function parses the "path" variable, implementing a conversion from ascii digit string to size of data. The conversion uses a 32 bit integer, the max value being 4294967295. We can repro this by asking:

.\picoquicdemo test.privateoctopus.com 4433 /4294977296

That number is 2 power 32 plus 10000. Sure enough, we get the response:

Stream 0 ended after 10000 bytes
All done, Closing the connection.

The fix is a bit more complex than using 64 bit numbers in the conversion, because we need a couple other fixes:

• The length of objects are computed using size_t, which can be 32 bits or 64 bits depending on systems and compilers. It might be better to move every variable to 64 bit. Or maybe use "size_t" for the computations instead of "uint64_t", since 32 bit systems are typically small IOT devices.
• The negative number comes from casting lengths as "int" before formatting. That was lazy, and is an easy fix.
• The digit to number logic should check for overflow, and return an error immediately instead of sending a random number of bytes.
• The stream size is actually limited to 2^62 -1, and so is the total number of bytes that can be sent on a QUIC connection. We might want to return an error if this happens. Maybe refuse streams that exceed 2^62-1, and have overflow logic in the computation of max data.

[huitema]

@alexj0l please check whether PR #1439 solves the issue.

[huitema]

I have verified that PR #1439 solves the issue. The scenario parsing test has been updated, to check a GET of size 200,000,000,000 octets and a POST of 100,000,000,000 octets. Checking in the PR will close this issue.

[alexj0l]

Thanks, I will try it out! Should the fix make any performance difference if I run "*10:0:-:2000000000:0" or directly /20000000000?

[huitema]

Should work either way.

[alexj0l]

The reason I'm asking this is because with "*10:0:-:2000000000:0" I'm getting:

The orange line is the throughput of Picoquic at the outgoing interface of sender, while the other lines are some other QUIC implementations. The network has no added delay, no added loss but a bottleneck of 2000Mbit/s. When testing in a network without a bottleneck, Picoquic shows a throughput of 2.7Gbit/s (average over multiple runs). Therefore I'm not sure if the fix you provided in #1439 will make the throughput some more stable or not and would like to know your opinion on that, as I can't repeat the experiment at the moment.

[huitema]

Maybe you should open a different issue. What I see here is the transport approaching the bottleneck bandwidth, which seems close to what we should expect. What congestion control are you using?

[alexj0l]

Cubic in all of the implementations including Picoquic. Worth to mention that in case of Bottleneck of 500Mbit/s the Picoquic is straight aligned at the 500Mbit/s.

[huitema]

Please open a separate issue for "Cubic does not stabilize throughput to 2Gbps bottleneck", so other developers can find the discussion easily.

[nikoobaniasadii]

Hello everyone. I ran into a problem when take picoquicdemo test between the client and the server of mininet topology. connection freezes after it established.. am I right? or has a mistake been made? ./picoquicdemo -p 4433 -c ./ca-cert.pem -k ./ca-key.pem (for server host ) ./picoquicdemo -n test -G cubic -D 10.0.0.1 4433 "*60:0:-:150000000000:0" (for client host)

[huitema]

You are requesting to download 60 streams of 150,000,000,000 GB each, in parallel. That's going to take some time.

[nikoobaniasadii]

Thanks. how can I set more time for connection (60 second)?

[huitema]

Suppose the bit rate is about 2Gbps. 150GB = 1200 gigabits, so will take 1200/2 =600 seconds, 10 minutes. The simple picoquicdemo program will give you feedback after a stream is complete, so once every 10 minutes if the data rate is indeed 2Gbps, longer if for some reason the data rate is slower. If you want more frequent feedback, maybe try a shorter file size?