openziti / dilithium Goto Github PK

Develop a parallel implementation of westwood supporting the lockless model.

Westworld really wants to be built using connected UDP.

Retransmission events and duplicate ack events currently share the throttle_fraction property. Should incorporate different fractions for both signal types.

Implement a v0.1 version of the paired TCP+UDP protocol.

Survey:

RBUDP is a data transport tool and protocol specifically designed to move very large files over wide area high-speed networks (on the order of gigabits per second). This is a simple replacement for FTP which tends to do poorly over long distance high-speed networks.

Reliable Blast has two goals. The first is to keep the network pipe as full as possible during bulk data transfer. The second goal is to avoid TCP’s per-packet interaction so that acknowledgments are not sent per window of transmitted data, but aggregated and delivered at the end of a transmission phase.

https://www.evl.uic.edu/cavern/RBUDP/Reliable%20Blast%20UDP.html

Digest RFC 1323:

https://tools.ietf.org/html/rfc1323

A survey of more advanced congestion control topics and implementations.

The Addition of Explicit Congestion Notification (ECN) to IP:
https://tools.ietf.org/html/rfc3168

Robust Explicit Congestion Notification (ECN) Signaling with Nonces:
https://tools.ietf.org/html/rfc3540

Proportional Rate Reduction for TCP:
https://tools.ietf.org/html/rfc6937

Implement high and low limits for txPortal sizing. There are likely corner cases where the current implementation can starve itself of portal size and die.

Implement retransmission.

Current RTT time average is accumulated over a fixed 8-RTT window. Make window length configurable.

RTT probes currently at 1 second intervals. Make configurable. Higher RTT probe resolution may allow more efficient retx behavior.

TCP Westwood-inspired v0.2 implementation.

Implement a "metrics" instrument, which is able to capture changing data over time, for visualization.

Modify our Hello protocol to include a final acknowledgement.

Incorporate stats into the trace instrument, creating the uber-instrument for development.

Survey the entirety of TCP to check for implementation coverage (or intentional omittance):

https://hpbn.co/building-blocks-of-tcp/

Implement packetization according to a MSS.

Implement a proving grounds for comparing protocols across varyous WAN links, with multiple types of virtual machines, in fablab.

Similar to using every-n scaling to decrease portal size, use every-n with an accumulator to increase the portal size.

We're producing a lot of metrics data. Need to summarize this into something easier to visualize and work with.

Minimize the burn on runtime.futex. Get state management working without sync.Mutex and sync.Cond.

Iterate our basic v0.1 protocol to support "inline" acknowledgement. Inline acknowledgements are also cumulative, and indicate an acknowledgement "high water mark".

Slightly tricky in that we'll have to send acknowledgements even when there is no outbound data ready for shipment.

We're currently using a hard-coded RETX timeout.

Compute expected ACK arrival time based on observed RTT. If ACK does not arrive in window, RETX.

Memory handling trace. Finalization?

https://golang.org/pkg/runtime/#SetFinalizer

Can we augment our memory pool framework to include stack details, allowing us to trace sources of allocations and unrefs?

Implement keepalives in westworld2.

https://github.com/google/flatbuffers

Potentially much higher performance than ProtoBufs. Will probably cooperate better with memory pooling.

Implement basic MSS packetization. Currently relying on os-level fragmentation.

Use an inline flag to indicate session close.

Implement soft close in westworld2.

Experiment with using the size of the admitted data payload as a scaling factor for increasing the txPortal size, instead of a static increase.

Thorough survey of QUIC:

https://en.wikipedia.org/wiki/QUIC

iperf is nice and all, and people seem to respect that it's an arbiter of "truth" in terms of the performance of network pipes... but we also need a performance measurement tool, which verifies the integrity of the data traveling across the network.

Probably will look something like the loop2 tool in the ziti fabric.

Capture westworld2 configuration details alongside the metrics output. Use these details to create configuration annotations that are available in the analyzer.

https://github.com/lucas-clemente/quic-go

Configure RX/TX socket buffer sizes independently, and separately from poolBufferSz.

Next iteration of westworld/wb and the pooled buffer system behind them.

Modularize the dilithium influx code, such that it continues to work from the dilithium cmd, but make it embeddable so that it can be inserted into fablab to automate retrieval of remote metrics and insertion into the analyzer.

Capture and analyze perceived tunnel performance at the client and server, regardless of underlying protocol. This will allow us to produce metrics and graphs regardless of protocol.

Implement basic congestion control, similar to the stock Nagle implementation:

Congestion Control in IP/TCP Internetworks:

https://tools.ietf.org/html/rfc896

TCP Congestion Control:

https://tools.ietf.org/html/rfc2581

What can we learn from the Westwood[+] implementation of TCP?

TCP Westwood significantly increases fairness wrt TCP (New) Reno in wired networks and throughput over wireless links.

Because dilithium.

Implement a pluggable soft-start and congestion control implementation for proving grounds testing.

An initial implementation of memory pooling for westworld.

Head to the APAC regions with the most onerous conditions, and square off with tcp.

Implement a clean close signal.

Implement buffer pooling.

Get Google Netstack up and running in our testing harness.

https://github.com/google/netstack/

See what we can learn from their user-space golang network stack implementation.

We're going to want to run various configurations of westworld against one another, without having to recompile our dilithium executable. Externalize the various tunables, such that we can run different variants of the configuration against one another for comparison.

I have a theory that the jumbo frame "cheat" is ultimately adjusting down the sensitivity of the portal scaling. Introducing an "every-n" sensitivity adjustment to portal scaling events might achieve the same effect.

Implement an Instrument, which can produce detailed trace output.

Implement random starting sequence numbers. The hello portion of the protocol already supports starting from a non-zero sequence number.

Ensure that sequence number rollover is operating correctly (it most certainly is not, currently).