Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

read ECN bits and send ECN counters in ACK frames #2741

Merged
merged 5 commits into from
Sep 15, 2020
Merged

Conversation

marten-seemann
Copy link
Member

No description provided.

@marten-seemann
Copy link
Member Author

marten-seemann commented Sep 5, 2020

Note the following API design problem that this PR brings:

Users pass a net.PacketConn to quic.Listen and quic.Dial. Currently, we'd use ReadFrom to read packets, but in order to read the ECN bits we'lll have to use ReadMsgUDP instead of ReadFrom on the net.UDPConn.
The problem is now that users might expect that quic-go will use the ReadFrom function of the packet conn. The question is now under which conditions to enable ECN support. Several options come to mind:

  1. Only use ECN if the packet conn is a *net.UDPConn. This is probably the safest option, as there’s no way a user could have wrapped methods on this struct. However, it’s also the most inflexible, as users might want to wrap the UDP connection for a variety of reasons.
  2. Define a new interface type quic.ECNCapableConn interface { net.PacketConn; ReadMsgUDP(…); WriteMsgUDP(…); SyscallConn(…); }, and do an interface assertion. This API is more flexible, but it requires more care from users: Directly embedding a packet conn type wrappedConn struct { net.UDPConn } would make quic-go bypass ReadFrom, which might be surprising. To prevent this, users would have to indirectly embed (is there any better term for this?) type wrappedConn struct { conn net.UDPConn} and then explicitly define all functions on wrappedConn such that it fulfills net.PacketConn.
  3. Require packet conns that want to use ECN to implement a UnwrapConn() *net.UDPConn method.

Currently, this PR implements option 1, but I'm leaning towards implementing option 2 (with appropriate documentation of the pitfall described above).

@codecov
Copy link

codecov bot commented Sep 15, 2020

Codecov Report

Merging #2741 into master will increase coverage by 0.00%.
The diff coverage is 88.97%.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #2741    +/-   ##
========================================
  Coverage   86.90%   86.90%            
========================================
  Files         128      133     +5     
  Lines        9999    10102   +103     
========================================
+ Hits         8689     8779    +90     
- Misses        982      990     +8     
- Partials      328      333     +5     
Impacted Files Coverage Δ
internal/protocol/protocol.go 100.00% <ø> (ø)
qlog/event.go 96.70% <33.33%> (+0.53%) ⬆️
multiplexer.go 94.87% <50.00%> (-5.13%) ⬇️
conn_ecn.go 80.39% <80.39%> (ø)
packet_handler_map.go 77.40% <85.71%> (-1.47%) ⬇️
conn.go 100.00% <100.00%> (ø)
conn_helper_darwin.go 100.00% <100.00%> (ø)
conn_helper_generic.go 100.00% <100.00%> (ø)
internal/ackhandler/received_packet_handler.go 76.06% <100.00%> (ø)
internal/ackhandler/received_packet_tracker.go 86.96% <100.00%> (+1.77%) ⬆️
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1914e5f...be7536f. Read the comment docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants