iperf3 cannot set tcp congestion algorithm

[Mic92]

Description of the problem

When trying to connect to iperf3 -s it close the connection with the following error:

iperf3: error - unable to set TCP_CONGESTION: Supplied congestion control algorithm not supported on this host

There was no congestion algorithm explicitly set via --congestion flag

Steps to reproduce

Graphene commit use: 08e2177

Expected results

graphene passes all setsocketopt syscall cleanly to the operating system.

Actual results

According to strace the system call is never done to the host.

[Mic92]

Current workaround is to compile iperf3 without this option:

$ iperf3_cv_header_tcp_congestion="no" ./configure

[mkow]

Expected results
graphene passes all setsocketopt syscall cleanly to the operating system.

The issue here is that we emulate Linux, not just forward everything to the host (because of this approach it's possible to port Graphene to non-Linux hosts without rewriting everything).

I'm not sure if we want to emulate this flag, it would require changes to PAL API.

@dimakuv any thoughts?

[dimakuv]

@Mic92 As Michal mentioned, Graphene doesn't forward everything to the underlying host (for both portability and security reasons).

1. Do you think TCP_CONGESTION is a rather important option? Or 99% of applications don't use it? In the latter case, there is no reason to support this option in Graphene.
2. Do you think simply ignoring this option would be fine? Or would it be surprising to users (that they explicitly set this option but the app doesn't change its behavior)? If ignoring this option is fine, then we can easily implement it in Graphene.

[Mic92]

@Mic92 As Michal mentioned, Graphene doesn't forward everything to the underlying host (for both portability and security reasons).

1. Do you think `TCP_CONGESTION` is a rather important option? Or 99% of applications don't use it? In the latter case, there is no reason to support this option in Graphene.

2. Do you think simply ignoring this option would be fine? Or would it be surprising to users (that they explicitly set this option but the app doesn't change its behavior)? If ignoring this option is fine, then we can easily implement it in Graphene.

I can probably live without it, its just that I came across the issue and have posted a work-around that makes iperf3 usable in this case.

[dimakuv]

Ok, thanks for explanation. We'll keep this issue open for the future. Maybe we'll implement it one day.

[mkow]

Closing, I don't think we'll implement this flag anytime soon, it would hurt portability.