It only affects the handshakes, then it's all AES. Stop making lots of connections and use long lived connections. But like you said, how are the measuring it. 20% just for the handshake or 20% on average per web request?

Newer DWMD multiplexing tech allows for 400Gb-500Gb super-channels and near future versions are about to have 1Tb/s super-channels. A 500Gb single super-channel can support anything from 50 10Gb channels to a single 500Gb channel. Of course the current max bandwidth across all channels in a single fiber is about 32Tb/s, so they'll have to make do. 32Tb/s can have 320 100Gb/s streams. Suddenly 100Gb sounds slow.

I assume the money issue is more of a legacy system issue. Some hardware that an ISP purchases is very expensive and you only replace every 8 years. Maybe the last time they ordered some hardware, they wanted to save 20% to get some older equipment that didn't support IPv6. I know I can purchase a Layer 3 switch that does not support IPv6 for a decent chunk less than one that does.

All new equipment for a long time has supported IPv6, but why purchase new when you can purchase a generation or two old and get liquidation prices? When my ISP purchased all new gigabit fiber and replaced their core router with a new shiny one that has more 10Gb and 100Gb ports than they'll need for a long time, I'm sure it supports IPv6, but there is bound to be a few pieces of old gear that needs to go away. Then they need to get training and do planning before they attempt to roll it out.

They don't "own" them, they have a civil contract that says ARIN has granted them the right to use them and ARIN can't forcefully take them back as long as the original contract is valid. As soon as the IP blocks transfer owners, they are no longer grandfathered in. There have been a few exceptions to this rule early during the transitional phase, but ARIN is locking down on any more exceptions.

You can't use the high and low IPs and you at least need a gateway ip. 3 IPs per subnet are lost. I'm not sure what the 4th IP gets lost to.

Many set-top boxes like Roku support streaming from your home media server. They'll need LAN access in those cases.

"Built in caching proxy server" - Doesn't help with HTTPS and with just around the corner 10Gb internet, I challenge you to make a cheap device that can handle proxying data at 10Gb/s.

"The device needs a real time virus scanner that is automatically updated" - Not so much a virus scanner, but an IDS. Can't virus scan at 10Gb/s.

"Must of course include basic traffic shaping and other useful stuff" - Even professionals get Traffic shaping wrong most of the time. An AQM like Cake or fq_Codel is all that is needed. Fair queueing and flow isolation to combat bufferbloat.

"You could even use VPNs to link two homes together" - More features!

You have a lot of great ideas, but as it is, even $400 consume grade routers are riddled with security holes that never get fixed. They can't even get NAT or UPNP right, what makes you think they can do some of the more complicated features in a secure way? Remember, most of these devices are EoL by the time they can be purchased. Supporting devices is a cost and most companies don't want that.

Either people need to take responsibility for their own security or we need a better open source security framework and support that allows for companies to make the devices and let the opensource community handle the software side of things. We cannot trust companies to maintain bug fixes for their devices.

"Slow start" is relative. It is much slower than going strait to line rate, but it is an binary search that increases bandwidth exponentially per RTT. Many TCP implementations start off with a window size of 8 segments or more at full line rate. Most TCP implementations coalesce ACKs to reduce the number of ACK packets. This would mean every 2 segments gets an ACK. 8 segments sent means 4 ACKs which means 4 doulbings(16x) in just the first RTT. 16x 8 segments is 128 segments. a 20ms RTT with 128 1500 byte segments is 76.8Mb/s in the first 20ms, and will continue to double every 2 segments ACKed per RTT. By the time you are 40-60ms in, you should be at almost 200Mb/s. His 15 seconds is forever.

My example is a little bit simplified because once a TCP stream gets moving, the packets are spaced apart, only the initial transfer will burst all segments in the window at line rate. A bit of trivia. Google modified their TCP stack to increase the number of initial bursted segments because most responses are quite small, and if you can fit the entire response in the initial burst the client only needs to wait one RTT, but if there are any more segments to be sent, the client now has to wait at least 2-RTTs, even if it's one more segment.

I have a 1Gb link that is rate limited to 100Mb. When I download files, wireshark shows a 1Gb burst of 30 1500 byte packets back-to-back, then my ISP's rate limiting starts to clamp down and the traffic shaping starts to space out the TCP flow and dials down to my 100Mb provisioned rate. This all happens in the first second, not 15-20 seconds. Although I have an 10ms RTT to every major datacenter in Chicago via Level 3 Comm. Low RTTs allow TCP to quickly ramp up. My ISP does have one CDN on their network, akamai. 1.5ms ping.

10ms to Chicago, 30ms to New York City and Atalanta and Washington(AWS), 40ms to Texas and Florida, and 60ms to Cali. Short RTTs help a lot with TCP.

Bandwidth isn't everything, ping, jitter, and loss are also important. Jitter typically indicates congestion and so does loss. I can reach every major datacenter in the world with under a 250ms RTT. That includes Moscow, India, China, Japan, South Korea, New Zealand, and Australia. Also, all under 1ms of jitter.

Except they legally own those IP blocks because of contracts when rules were different a long time ago. Mob rule, steal people's property!

ARIN already laid out several phases. A few months ago they started to limit how many IPs they handed out, a month ago they started to reject some requests. We're reaching the end game, which includes reclaiming IPs. You will need to prove every year that you still need your blocks more than others, and every year ARIN will get more strict and refuse renewal for some customers so other customers that are more deserving get some. It will start to get painful.

Some CDNs are seeing 18%-40% of web requests from AT&T, Verizon, or Comcast are over IPv6. IPv6 is still growing at an exponential rate for almost a decade now, about 100% per year. At the current about 10% of all USA, given 100% growth that hasn't shown any signs of stopping, we'll be at 40% in two years and 80% in 3 years.

HTTP1.1 is a huge limitation. You need a lot of connections to make any decent use of your bandwidth. I find that even slow websites are mostly a latency vs throughput issue. The data comes in bursted at 1Gb/s, but there are large gaps between the responses.

Not just block sized inserts, but also inserts at block boundaries. And block sized inserts only works for dedup. CoW won't help with dedup off if the blocks shift, but no issues flipping bits or appending.

We don't need a /48 per person, just per household. With 3 people per household, that's saves you almost 2 bits! Meant to be funny. 1 bit isn't that useful of a difference.

More like 5 IPs per computer. Each for different usages.