search

p-quic / pquic

The PQUIC implementation, a framework that enables QUIC clients and servers to dynamically exchange protocol plugins that extend the protocol on a per-connection basis
https://pquic.org
MIT License
126 stars 20 forks source link

Adding plugins insreases transmission time. #9

Closed mayankmclaren closed 3 years ago

mayankmclaren commented 4 years ago

Hi, I ran picoquicdemo with different plugins. But I observed that the plugins which should have decreased the transmission time of the data actually end up increasing time taken.

picoquicdemo with no plugin took 8755.857 ms for around 100MB of data. Screenshot from 2020-06-23 04-28-39

picoquicdemo with datagram plugin took 9469.609 ms for around 100MB of data. Screenshot from 2020-06-23 04-28-42

picoquicdemo with datagram, fec and multipath plugins took 14611.648 ms for around 100MB of data. Screenshot from 2020-06-23 04-28-47

Is it supposed to happen like this or there is something that I'm doing wrong? Am I missing out anything important regarding the plugins?

mpiraux commented 4 years ago

I guess those tests are running on the loopback interface. In the original PQUIC paper (available at pquic.org) we also report on performance benchmarks and provide explanation on the performance degradations. In short, plugins are eBPF bytecodes and thus are slower than native machine code. Also, injecting plugins add new functions and code paths to PQUIC, so the execution time increases.

That said, injecting plugins can be beneficial. FEC helps in lossy networks, such as SATCOM environments, but can be detrimental in good networks and Multipath can leverage several network paths. When running a test on the loopback, you are first likely to be CPU blocked rather than network blocked, and second losses are absent.

Regarding the injection of the datagram plugin. I am surprised to see a performance degradation as picoquicdemo does not use datagrams in any forms. I would expect that if you run the tests several time, you will not find a statistically meaningful difference. If you find one, it would be interesting to understand its origin.

mayankmclaren commented 4 years ago

I ran picoquicdemo with and without datagram plugin sending 100MB of data on loopback condition for 50 times. The average transmission time without the plugin injected was 9.223 seconds and with the plugin injected was 10.095 seconds. I also observed that a few times the datagram plugin took time all the way up to 14.5 seconds. I'm attaching the test data here: https://docs.google.com/spreadsheets/d/1vvfdTFZ0OX7mpczngmCTzWVM5NIoHRWBbzo1sjjm3wc/edit?usp=sharing

mayankmclaren commented 4 years ago

there's one more question that I want to ask.
On the server side at the end, it shows "Retrans= (some numeric value)". What does that signify? The number of times retransmission happened?

Screenshot from 2020-06-23 04-28-39 like here it's Retrans= 543

mpiraux commented 4 years ago

I think there is something odd with your test setup. I can transfer 1Gb in about a second on my machine loopback (disabling the logs with -l /dev/null), and the transfer does not report any retransmitted packet. Injecting the datagram plugin adds a fixed cost of reading a bunch of files and recompiling their code, but it does not add any instructions in the data path when using the picoquicdemo client and server. I ran 20 tests side by side with and without the plugin and I did not find a meaningful difference. There is theoretically one, but a small one.

mpiraux commented 3 years ago

I am closing this as it seems that no further assistance is required.