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.

Sign up for GitHub

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

Jump to bottom

Add QUIC support #4402

Closed
AgeManning opened this issue Jun 14, 2023 · 4 comments
Closed

Add QUIC support #4402

AgeManning opened this issue Jun 14, 2023 · 4 comments
Assignees
@AgeManning
Labels
Networking

Comments

@AgeManning
Copy link
Member

Description

Initial tests show significant performance improvements (bandwidth and latency) with the QUIC protocol. Lighthouse is capable of supporting this amongst itself with other compatible lighthouse nodes. We can therefore test this transport fairly easily and see the results.

This requires our own ENR standard, we also need to add some metrics that indicate the type of transport used in order to effectively evaluate the difference between this transport and regular TCP.

This will be fully backwards compatible.
@AgeManning AgeManning self-assigned this Jun 14, 2023
@ameya-deshmukh
Copy link

@AgeManning is this something still on your radar? Would love to see if I can work on this!

@AgeManning
Copy link
Member Author

Hey @ameya-deshmukh

Thanks for the interest. It is on my radar and is a fairly trivial update. I was just waiting for us to update to the latest libp2p, making sure that is stable then adding in quic support.

Supporting QUIC is a fairly trivial change (we just add an extra transport) and we need to specify a new ENR field. The rest is mainly documentation and testing.

If this is something you'd like to do, feel free make a PR (probably best for just the transport) then we can discuss how we want the ENR to look and also whether it is on by default. I was thinking a default port of 9090.

@ameya-deshmukh
Copy link

Sure!

@AgeManning AgeManning mentioned this issue Aug 8, 2023
Closed
bors bot pushed a commit that referenced this issue Sep 12, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
3dd54f8 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 12, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
bae37ba 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 12, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
906ee22 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 12, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
2c9171e 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 13, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
c18acef 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 13, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
458be38 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 13, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
35d9a72 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 13, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
83d51f2 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 13, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
2941036 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 14, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
0eb0a99 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
bors bot pushed a commit that referenced this issue Sep 15, 2023
@AgeManning @jxs
Add Experimental QUIC support (#4577)
e4ed317 
## Issue Addressed

#4402 

## Proposed Changes

This PR adds QUIC support to Lighthouse. As this is not officially spec'd this will only work between lighthouse <-> lighthouse connections. We attempt a QUIC connection (if the node advertises it) and if it fails we fallback to TCP. 

This should be a backwards compatible modification. We want to test this functionality on live networks to observe any improvements in bandwidth/latency.

NOTE: This also removes the websockets transport as I believe no one is really using it. It should be mentioned in our release however.


Co-authored-by: João Oliveira <[email protected]>
@jxs
Copy link
Member

jxs commented Sep 18, 2023

addressed on #4577

@jxs jxs closed this as completed Sep 18, 2023
@jmcph4 jmcph4 mentioned this issue Sep 19, 2023
Closed
bors bot pushed a commit that referenced this issue Sep 29, 2023
@jmcph4
Allow libp2p to determine listening addresses (#4700)
65f6772 
## Issue Addressed

#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - #4705 
 - #4402 
 - #4745
bors bot pushed a commit that referenced this issue Sep 29, 2023
@jmcph4
Allow libp2p to determine listening addresses (#4700)
3004217 
## Issue Addressed

#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - #4705 
 - #4402 
 - #4745
bors bot pushed a commit that referenced this issue Sep 29, 2023
@jmcph4
Allow libp2p to determine listening addresses (#4700)
d45e79b 
## Issue Addressed

#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - #4705 
 - #4402 
 - #4745
bors bot pushed a commit that referenced this issue Sep 29, 2023
@jmcph4
Allow libp2p to determine listening addresses (#4700)
c9f48f3 
## Issue Addressed

#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - #4705 
 - #4402 
 - #4745
bors bot pushed a commit that referenced this issue Oct 3, 2023
@jmcph4
Allow libp2p to determine listening addresses (#4700)
1c98806 
## Issue Addressed

#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - #4705 
 - #4402 
 - #4745
Woodpile37 pushed a commit to Woodpile37/lighthouse that referenced this issue Jan 6, 2024
@jmcph4 @Woodpile37
Allow libp2p to determine listening addresses (sigp#4700)
63ed24e 
## Issue Addressed

sigp#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - sigp#4705 
 - sigp#4402 
 - sigp#4745
Woodpile37 pushed a commit to Woodpile37/lighthouse that referenced this issue Jan 6, 2024
@jmcph4 @Woodpile37
Allow libp2p to determine listening addresses (sigp#4700)
3b35917 
## Issue Addressed

sigp#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - sigp#4705 
 - sigp#4402 
 - sigp#4745
Woodpile37 pushed a commit to Woodpile37/lighthouse that referenced this issue Jan 6, 2024
@jmcph4 @Woodpile37
Allow libp2p to determine listening addresses (sigp#4700)
bb2090f 
## Issue Addressed

sigp#4675 

## Proposed Changes

 - Update local ENR (**only port numbers**) with local addresses received from libp2p (via `SwarmEvent::NewListenAddr`)
 - Only use the zero port for CLI tests

## Additional Info

### See Also ###

 - sigp#4705 
 - sigp#4402 
 - sigp#4745
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AgeManning AgeManning

Labels
Networking
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jxs @AgeManning @ameya-deshmukh