A while ago I found an interesting analysis of HTTP/2 behavior under adverse network conditions. Not surprisingly:
When there is packet loss on the network, congestion controls at the TCP layer will throttle the HTTP/2 streams that are multiplexed within fewer TCP connections. Additionally, because of TCP retry logic, packet loss affecting a single TCP connection will simultaneously impact several HTTP/2 streams while retries occur. In other words, head-of-line blocking has effectively moved from layer 7 of the network stack down to layer 4.
Here’s another back-to-the-fundamentals question I received a while ago when discussing IPv6 multihoming challenges:
I was wondering why enterprise can’t have dedicated block of IPv6 address and ISPs route the traffic to it. Enterprise shall select the ISP's based on the routing and preferences configured?
Let’s try to analyze where the problem might be. First the no-brainers:
Andy sent me this question:
I'm currently playing around with BGP & VXLANs and wondering: is there anything preventing from building a virtual IXP with VXLAN? This would be then a large layer 2 network - but why have nobody build this to now, or why do internet exchanges do not provide this?
There was at least one IXP that was running on top of VXLAN. I wanted to do a podcast about it with people who helped them build it in early 2015 but one of them got a gag order.
Level3 had a pretty bad bad-hair-day just a day before Pete Lumbis talked about Continuous Integration on the Building Network Automation Solutions online course (yes, it was a great lead-in for Pete).
According to messages circulating on mailing lists it was all caused by a fumbled configuration attempt. My wild guess: someone deleting the wrong route map, causing routes that should have been tagged with no-export escape into the wider Internet.
Every now and then someone looks at a few recent BGP incidents (from fat fingers to more dubious ones) and says “we need a better BGP”.
It’s like being unable to cope with your kids or your team members because you don’t have the guts to tell them NO and trying to solve the problem by implementing new procedures and rules.
Like anything designed on a few napkins BGP has its limit. They’re well known, and most of them have to do with trusting your neighbors instead of checking what they tell you.
One of my readers sent me this question:
One thing that I notice is you mentioned moving the complexity to the upper layer. I was wondering why browsers don't support multiple IP addresses for a single site – when a browser receives more than one IP address in a DNS response, it could try to perform TCP SYN to the first address, and if it fails it will move to the other address. This way we don't need an anycast solution for DR site.
Net neutrality is one of those topics that should never have existed, but of course it inevitably erupts every so often, so here we go…
Not so long ago Robert Graham published his anti-net-neutrality arguments which are (no surprise) not much different from what I wrote when I still cared about this argument (here, here, here and here). While I agree with his overall perspective, I completely disagree with his view of Comcast’s initial response to network congestion.
Marco Canini from UC Louvain is working on an IXP research project focused on bringing privacy guarantees into Internet routing context. They’re trying to understand the privacy considerations of network operators and have created a short survey to gather the initial data.
Researchers from UC Louvain have been involved in tons of really useful projects including BGP PIC, LFA, MP-TCP, Fibbing, Software-defined IXP and flow-based load balancing, so if you’re connected to an IXP, please take your time and fill in the survey.
One of the oft-repeated messages of the Software-Defined Pundits is “Standard bodies are broken, (open) source code is king”… and I’d guess that anyone who was too idealistic before being exposed to how the sausage is being made within IETF has no problems agreeing with them. However…
Failure to use DNS, IP addresses embedded in the code, ignoring the physical realities (like bandwidth and latency)… the list of mistakes that eventually get dumped into networking engineer’s lap is depressing.
It’s easy to reach the conclusion that the people making those mistakes must be stupid or lazy… but in reality most of them never realized they were causing someone else problems because nobody told them so.
You might remember the great idea David Barroso had last autumn – turn an Arista switch into an Internet edge router (SDN Internet Router – SIR). In the meantime, he implemented that solution in production environment serving high-speed links at multiple Internet exchange points. It was obviously time for another podcast on the same topic.
A while ago I started discussing the intricate technical details of fibbing (an ingenious way of implementing traffic engineering with traditional OSPF) with Laurent Vanbever and other members of his group, and we decided to record a podcast on this topic.
These presentations focus more on the application-level technologies (client- and server side), but I’m positive you’ll find some useful content in the caching and scale-out applications with load balancing sections.
“Daddy, why is Internet not working even though I have good signal?”
“You really want to know?”
“OK, let me draw a diagram or two ;)”
… and now my 8-year old knows how DHCP and DNS works (root cause was a broken DNS proxy running on upstream $0.99 WAN router).