> I would never be in the top tier for bandwidth usage even if I was connected all day long
Maybe, but it probably doesn't depend on you unless you are your own AS. Routing tables do not contain individual IP addresses so if you are a "normal" ISP consumer chances are you will be in a block that is in the top 10%.
I remember the days when ARIN would give out AS's to basically anyone. Before all the cable companies merged, I spent my teenage years developing close relationships to my ISP. One of the high level techs told me to throw up BGP on a FreeBSD box and got on the ARIN mailing list with me to get a /30. That's the type of AS that'd fall into the 90 percent category (along with small businesses that who, for whatever reason, have their own AS). Even on my own AS, I'd rarely see latency above 50 ms domestically via BGP or OSPF.
My home IP falls into a slash /22 block I can see in the global routing table. It's highly unlikely that this particular 1000ish IP addresses are responsible for enough traffic on the internet to make top 10%. Top 10% is going to basically be a bunch of hosting providers and CDN prefixes.
If routers become cheaper and smarter the network will grow, you might get more direct routes (less hops), or simply better load balancing (based on latency and-or throughput, maybe even indicated by the size of the flow, so your SSH session will be low latency low jitter but also if you start to download a file via a subchannel it might get shifted to different routers), and with better balancing flows will get distributed not just considering packet drops, but maybe cache hits too (latency basically).
Anyhow, upkeep costs are very important, because they limit the size and efficiency of the network. (High barriers to entry limit growth, high upkeep encourages centralization, which is bad from a reliability and fault tolerance aspect.)
on modern software forwarding core (fd.io/VPP and DPDK) you can forward with a sub 100us latency. so your total latency ends up being roughly 1.7ms "slower".
have a look at this: https://www.youtube.com/watch?v=T66BTHnENY8
yes, but current COTS hardware, via userspace networking can very easily saturate a 10g interface at 64b packet-size / core.
imho, it is the convergence of a large number of advances in COTS hardware over the last couple of years, that has changed the field to mostly a software problem rather than a combination of hardware + software one. when you have proprietary hardware, software tends to be more or less proprietary, which is where most of the networking vendors are currently.
a large number of projects are actively attacking this space e.g. snabb(https://github.com/lukego/snabb), routebricks (http://routebricks.org/) etc.
This is on bare metal though, so might be different experience if you are running stuff on vm's where without sr-iov you would have multiple layers of indirection + context switches before someone can actually do something meaningful to the pdu...
edit: slight clarification added
Citation needed.
http://www.ieee802.org/3/10G_study/public/speed_adhoc/email/...
What are you talking about?
I think the worst-case, steady-state, scenario is actually equal time sharing, and the whole value is that while you aren't talking, other packets flow faster. That's not a doomsday scenario. Noone is out anything. (If this equal-sharing isn't fast enough, your upstream links/peers are over-subscribed.)
Also, your cache/memory analogy disrgards the possibility of simplifying and/or distributing the routing tables.
Route consolidation is one solution. Having no table at all is ideal. My little underpowered home router has 1 entry for it's upstream gateway. There's no reason to keep billions of records in a table in any central router either, given there are only going to be so many uplinks.
The more scalable solution is to distribute the table(s) in parallel to other peers. If the routing tables really are too big and can't be consolidated in core routers, the answer is simply more routers, geographically distributed to best meet demand, not fatter ones in the core, with higher latency, higher costs, and all the downsides of centralization like survaillance.
QoS is a solution in search of a problem; networks scale fine when we scale them out, not up.
What he is suggesting will drastically impact the latency of packets as well as the throughput. Following his analogy of cache hierarchies in a regular computer, some prefix lookups are going to be 'downgraded' to the main memory and will take maybe 100x the time.
If a router is forwarding at 10gbps it has ~51 nanoseconds in worst case (64 byte packets). So this is the overhead you can probably expect at each router as your traffic traverses the net. I'm 17 hops from my old university's network. That's just under a microsecond of lookup times. Not bad thanks to TCAM or other specialized lookup chips.
If all of these routers adopted this, my lowly traffic would have to read from main memory on each route lookup because I would never be in the top tier for bandwidth usage even if I was connected all day long. A full routing table is >600k addresses now[1] so each lookup may have to reference main memory several times as it walks a trie. Let's assume about 10 times to be generous which (at 100ns a reference) comes to about 1 microsecond. This is just for 1 packet.
As you start to pile on the thousands of other small connections (we're talking about provider network routers) that would be put into this steerage class, there is going to be contention and queuing that could easily push it into 1ms-10ms depending on bursts.
So if my whole path adopted these routers, I could experience jitter of ~170ms or worse. Gross.
This is essentially turning into a crappy QoS system where the biggest bandwidth hogs get the good service and everything else gets garbage.
Thumbs down from me.
1. http://www.cidr-report.org/as2.0/