Hey,
I have been dreaming of a project similar to this for a while already and I was actually surprised to see how micro stacks aren't that common. Thanks for filling the gap, just wired this into a test build of usque and it works wonderfully.
I think adding a method that disabled congestion control would be very useful in some cases. ie there are people who chain warp in warp. There, because of the chaining, the chain becomes warp(outer_ipstack(warp(inner_ipstack()))). Here the inner one should do both congestion and flow control, but for the outer one there is most likely no need for any CC at all (unless some goroutine locking caused latency happens, but that's very unlikely and inner one will handle it fine).
I see a point in flow control, because it's hard to know at any layer how many pkts can we send, but CC will just get confused by chaining or will do calculations for no reason.
Since this stack was built with seemingly easy flexibility in mind for that, I am wondering if you would consider either adding a None CC mode or have a way to signal RTTs and other metrics from outer layers to inner ones so the CCs know about each other when one chains together.
Also a bit off topic question, but isn't worth opening a new thread for: how much of this is vibe coded? Code looks solid upon first glance, but shockingly solid for such a short period of existence (which is not a bad sign at all, just making sure!). Especially TCP implementations have many flavors and interpretations. What was used as a reference? Would love to know how much auditing went into it already so I can place it on the production readyness scale. ☺️
Thanks for this once again, super exciting times :)
Hey,
I have been dreaming of a project similar to this for a while already and I was actually surprised to see how micro stacks aren't that common. Thanks for filling the gap, just wired this into a test build of usque and it works wonderfully.
I think adding a method that disabled congestion control would be very useful in some cases. ie there are people who chain warp in warp. There, because of the chaining, the chain becomes
warp(outer_ipstack(warp(inner_ipstack()))). Here the inner one should do both congestion and flow control, but for the outer one there is most likely no need for any CC at all (unless some goroutine locking caused latency happens, but that's very unlikely and inner one will handle it fine).I see a point in flow control, because it's hard to know at any layer how many pkts can we send, but CC will just get confused by chaining or will do calculations for no reason.
Since this stack was built with seemingly easy flexibility in mind for that, I am wondering if you would consider either adding a None CC mode or have a way to signal RTTs and other metrics from outer layers to inner ones so the CCs know about each other when one chains together.
Also a bit off topic question, but isn't worth opening a new thread for: how much of this is vibe coded? Code looks solid upon first glance, but shockingly solid for such a short period of existence (which is not a bad sign at all, just making sure!). Especially TCP implementations have many flavors and interpretations. What was used as a reference? Would love to know how much auditing went into it already so I can place it on the production readyness scale.☺️
Thanks for this once again, super exciting times :)