And you are here why?

 /via http://www.commitstrip.com/en/2018/06/19/the-world-cup-and-the-sysadmin/ We’ve tried many variations over the years — the one I found the most effective was to actually just put the game up on the TVs that are liberally distributed around our offices. ( And yes, we even bought a couple of extra TVs for a few of the neglected walls, to make sure… )

________________________________________________________________ This is part of a series on Direct Server Return 1.  A Quick Primer 2.  SYN Floods 3.  The Real World ________________________________________________________________ DSR can be remarkably useful in asymmetric traffic environments, where the traffic  to  you is a lot less than the traffic  from  you (think Netflix, YouTube, and, well, pretty much any streaming service you can think of. Packet Rewrites In  a previous article , I used the above diagram to show how, with DSR, the response traffic went directly back to the Client. Mind you, there  is  a little bit of chicanery going on here — even though the traffic is originating from t the packet now looks like it is addressed to  Server B IP:Server B Port , the actual network packets show that they are originating from  Router IP:Router Port . Where did that happen? The answer is, well,  it depend...

So you’ve got an app that you put up on a server. It’s something important, say, a place where people can get advice from each other on making their own wood-fired pizza ovens. A) Direct Access In a very simple scenario, once you set things up, people would access the app by going directly to your server as shown below If you looked at the actual packets, they would show the source as the client’s IP:Port and the destination as the   ServerIP:ServerPort B) Multiple Servers You’ve now got a whole bunch-a people using your app, and you need multiple servers to handle the load. You’re still keeping this simple, and you just tell people to go directly to one of your servers (and if it’s overloaded, pick a different one). If you looked at the actual packets, they would show the source as the client’s IP:Port and the destination as either   Server A IP:Server A Port or   Server B IP:Server B Port depending on which server the packet is going to. C) Router Now, y...

The folks at Azure are using   FPGAs to accelerate network performance   (and decrease host-CPU utilization) in their public cloud. There’s a nifty paper about this that was presented at NSDI ’18 (•). It’s worth reading (as is   the writeup   by   Adrian Colyer ), but the following graphs, showing the network performance of Azure vs GCP vs AWS, really caught my eye. /via https://bit.ly/2HGZtBT   Ignore the Azure bars (ok, don’t ignore them, they’re pretty nifty, but they’re not the focus here). Notice how GCP’s VM-VM latencies are better than AWS’, but   the tail latencies are much worse ? Turns out there is a reason for this, and it’s embedded in the way GCP does networking, and specifically in the way their   Andromeda   network virtualization stack works. /via https://bit.ly/2HGZtBT You can ignore most of the stuff in the stack (shown above), except for the “ Hoverboard ”, which is, in effect a sidecar that is used to proce...

TL;DR —  “There is no evidence of the imminent collapse of BGP”   and none of the metrics indicate that growth is anything other than within router capacity. When we look at BGP (•) performance, and possible issues, there are two main things we tend to be concerned about • Routing Table Size  : since each router has a local db containing all the prefixes for each routing peer, and each of its line cards contains a decent subset thereof. Which translates to, at line speed, the need to do an imprecise 32-bit lookup on this ever-growing db in less than 5ns (yes, that’s hard!) • Update frequency (route churn)  : As this goes up, the router starts to lag, and eventually just drop, updates. At best, this means “ghost routes”, with the router reflecting some past state of the network. At worst, router loops, where a packet just goes round and round till it times out. Each just worsens the problem.   Geoff Huston looks at these problems , with metrics, and, defin...

Google released a patch today that significantly  improves how congestion control works in TCP . First, the great  part - the changes are on the sender  side, and require no co-ordinated changes on the receiver , or the intermediary network .  Which is awesome - it means that this can be incrementally deployed purely by updating the network stack at the end-points. Seriously, that is awesome news.  This field has been more art than science for the longest time, and despite the plethora of approaches out there , not much has really changed since the days of Reno. Part of the reason for this is the network equivalent of the Heisenberg Uncertainty Principle - where bandwidth and network delay are inextricably linked, and can't be disambiguated.  And the problem with that  is that it turns out that you really, really  want to look at the two independently to find the optimal operating point for a network . Anyhow, Google's new algorithm - c...