Suggestions for quinn-udp

[larseggert]

A few suggestions that would IMO make quinn-udp more useful, in no particular order:

• Conversion from EcnCodepoint into u8.
• Setting/getting IPv4 DSCP (IPv6 traffic class) info, i.e., the other six bits not used by ECN.
  • With similar u8 conversion for the whole field and the ECN/DSCP components individually.
• Setting/getting IPv4 TTL (IPv6 hop count) information on packets.
• Pacing offload via GSO (see quiche)

(NB: Rust newbie here, so some of these things might be doable already, but I couldn't quite figure out how).

[Ralith]

Conversion from EcnCodepoint into u8.

x as u8 will do this alrady, though the expectation is that you shouldn't need to do that yourself, since quinn-udp's responsible for passing it down

Setting/getting IPv4 DSCP (IPv6 traffic class) info, i.e., the other six bits not used by ECN.

This would be a straightforward extension. Any thoughts on how this should be exposed to the application layer by a QUIC impl?

Setting/getting IPv4 TTL (IPv6 hop count) information on packets.

Is this relevant to QUIC? We've been reluctant to let quinn-udp scope-creep into a generic UDP library.

Pacing offload via GSO (see quiche)

Pacing offload be cool to have, but seems pretty niche because it requires manual configuration of the kernel to be effective, so won't be useful for end users/unsophisticated deployments. Is there an easy way to automatically detect when it's available? Also, you say "via GSO", but it looks to me like this entire GSO batch is sent with a single txtime there?

[larseggert]

x as u8 will do this alrady, though the expectation is that you shouldn't need to do that yourself, since quinn-udp's responsible for passing it down

Doh. Of course.

Setting/getting IPv4 DSCP (IPv6 traffic class) info, i.e., the other six bits not used by ECN.

This would be a straightforward extension. Any thoughts on how this should be exposed to the application layer by a QUIC impl?

"It depends." Some DSCPs such as LE have straightforward semantics for an entire connection. Others may be better used for streams or individual QUIC datagrams (modulo the overall uncertainty if the network is equipped to deal with intra-flow DSCP changes.)

My main motivation here is to enable experimentation with DSCP and QUIC, which obviously needs the UDP I/O to allow this. IMO DSCP on the Internet was held back for decades because it is difficult to use from an application.

(Same is true for the IPv6 flow label. I didn't include it in the list in the first post, but if I ask for a pony, why not ask for a pink one...)

Setting/getting IPv4 TTL (IPv6 hop count) information on packets.

Is this relevant to QUIC? We've been reluctant to let quinn-udp scope-creep into a generic UDP library.

Understood. I really wish for a generic UDP I/O crate though :-)

One use of TTL in QUIC would be to take a TTL change on a path as an indication of a path (routing) change, an possibly do something congestion-control-related. Again, this would be for experimentation at this time, but again, the UDP I/O layer needs to support it to enable this kind of experimentation.

Pacing offload via GSO (see quiche)

Pacing offload be cool to have, but seems pretty niche because it requires manual configuration of the kernel to be effective, so won't be useful for end users/unsophisticated deployments. Is there an easy way to automatically detect when it's available? Also, you say "via GSO", but it looks to me like this entire GSO batch is sent with a single txtime there?

I might have misunderstood what quiche is actually doing, I just took a cursory glance. I had assumed that some of the concepts in this talk were available now in Linux and should hence be used. But I didn't actually check on the merge status of the associated PRs.

[djc]

Setting/getting IPv4 TTL (IPv6 hop count) information on packets.

Is this relevant to QUIC? We've been reluctant to let quinn-udp scope-creep into a generic UDP library.

I think I'd be open to some scope creep assuming there's not too much complexity, and I think we'll probably only passively maintain that stuff (that is, review incoming PRs). It seems wasteful if we're maintaining something that is the best UDP crate to require others to fork it on account of adding some (presumably small things)?