Google NetStack: IPv4 and IPv6 userland network stack in Go

Re:Google NetStack: IPv4 and IPv6 userland network stack in Go by diamondlovesyou on Thursday October 26, 2017 @07:09AM (#15557842)

It's not implementable by local devices: your LAN is much faster than your WAN link, in most cases. Your router/modem does the packet dropping. But only your router/modem knows how much unused throughput is available at any moment, so rsync can't know how much it can use. Sure, rsync can look at TCP packet retransmits, but that will still cause other streams to experience an (assuming a lot of things) "equal" amount of drops too.

So, you get a lot of complexity for not a lot of benefit. However, Fuchsia is destined for mobile devices, which may not have the LAN-WAN bottleneck, so this could see some benefit.

[ Parent | on HN ]

Re:Google NetStack: IPv4 and IPv6 userland network stack in Go by beagle3 on Thursday October 26, 2017 @09:00AM (#15558383)

The way ledbat works is by measuring the derivative of round trip time with respect to a throttled receive bandwidth. As long as RTT is constant or decreasing, keep increasing bandwidth; if RTT is increasing decrease bandwidth.

The server has to give you an indication of round trip for that to work - although I suspect there’s some clever way to get it using Some kind of URG or OOB or keep alive even if the server doesn’t natively support TCP ledbat.

[ Parent | on HN ]

Re:Google NetStack: IPv4 and IPv6 userland network stack in Go by toast0 on Thursday October 26, 2017 @10:55AM (#15559356)

If you've negotiated tcp timestamps, and you assume the server will send more data immediately when it gets an ack, you have a convenient round trip time signal in the echoed timestamps. If you don't have tcp timestamps, you can advertise a reduced window and time the round trip between acks that open up the window and packets with sequence numbers in the window.

[ Parent | on HN ]