quinn-udp: Performance degradation on Android.

[mstyura]

I'm using quinn inside Android application to tunnel connections to backend, such that quinn bidirectional channel serves as "tcp connection to backend".

I've noticed several degradations when recently upgraded from quinn-udp 0.5.5 to newer versions.

When I use quinn-udp 0.5.7 the application sometimes stuck after several minutes of use and only able to recover if some very long timeouts are happen and app is re-creating connections. Possibly when idle timeout expired. According to Wireshark no UDP packets leave device when problem happen.

When I use quinn-udp 0.5.9 everything functionally works, but it is visually observable that overall network performance is muuuuuch worse that it was before, application is functioning but what previously took 1-2 seconds to complete on quinn-udp 0.5.9 took 5-8 seconds to complete on quinn-udp 0.5.9.

I've noticed some new logs from quinn_udp on version 0.5.9 which were absent on version 0.5.5, which might be related:

01-28 12:14:53.965  2868  3224 I lhpr    : drive{id=0}: quinn_udp::imp: `libc::sendmsg` failed with I/O error (os error 5); halting segmentation offload
01-28 12:14:53.965  2868  3224 W lhpr    : drive{id=0}: quinn_udp: sendmsg error: Os { code: 5, kind: Uncategorized, message: "I/O error" }, Transmit: { destination: [xxxx:xxxx:x:xx::xxxx:xxxx]:443, src_ip: None, ecn: Some(Ect0), len: 1306, segment_size: Some(1200) }

As I noticed there was significant refactoring between 0.5.5 and 0.5.9, so it's likely there was some change which introduced performance degradation.

[djc]

Do you have a reproduction scenario you can trigger by hand? If so, bisecting the changes would be valuable.

[mstyura]

Yes, that's how I found out that there was no issues (at leat as my concern) inquinn-v0.5.5 and there was some severe functional issue in 0.5.7, which was fixed in 0.5.9, but performance regression for android (not checked other platofrms) was introduced. The basic scenario I have 10-20 concurrent bidirectional streams which are created and terminated while I use an app. I'm currently trying to add more logs on top of current master to debug issue further.

[Ralith]

Can you chart packet loss over time from your application over a long period? A GSO failure might be causing a lost flight early on, but that should recover in a reasonable amount of time and restore acceptable performance. Try reverting 46acdea and/or a694602, and/or try disabling segmentation offload in the transport config.

It'd also be interesting to know what android/Linux kernel version you're observing this on.