Guide to Innovative Proxy Solutions in Networking
Hi. Max Clark. I'm gonna talk about proxy servers. So if you've been on the Internet since the nineties, you've dealt with proxy servers, and usually it was in a very negative way. Right?
Speaker 1:We talk about the AOL mega proxy was the big big challenge in the late nineties and early 2000 if you were hosting any sort of web infrastructure. And, of course, at that point, AOL was a dominant player in Internet ISPs. It's kind of a redundant term there. And just dealing with having all the traffic aggregate. Now why were they aggregating traffic through the proxies?
Speaker 1:Well, it was network efficient for them. You know, proxies let you do fun things. What AOL was doing was it was doing, content caching. It was, you know, it was it was doing network, you know, aggregation. It was doing a bunch of different things with it.
Speaker 1:Boy, we always had fun with the, AOL mega proxies. And and if you were running any sort of web infrastructure back there, you remember it. You have scar tissue of it. You've been dealing with session, you know, session maintenance issues and and persistence problems and then, you know, all sorts of fun stuff. Now proxies weren't all bad.
Speaker 1:I mean, there were places where you would wanna use a proxy in your own infrastructure. Late nineties, early 2000, Internet connections were obscenely expensive. So when I started in networking, most small businesses were using dial up to get on the Internet. And, you can go through the bowels and and find Microsoft proxy server 1.0 and then update it eventually to 2.0. And, it was just software that you loaded on one of the windows in t four o servers in an office and connected to some modems to it.
Speaker 1:And what it did that was really cool is you could aggregate multiple modems together. So, you know, you could have one modem on it and have 56 k for an office, or you could put 2 modems on it, or, heck, you could have 4 modems on it. You could aggregate up to 4 modems on your dial up. And this was dial up ISPs. So 336 and 566 modems.
Speaker 1:And, of course, this was because, you know, the cost of ISDN and the cost of frame relay was just so expensive. You know, going out and putting a $1500 frame relay circuit in a small office versus, you know, 2 modems was just a different world. I mean, you're talking about a $100 a month expense versus a $1500 a month expense. It doesn't even it didn't I mean, you wouldn't even argue this. It didn't didn't go there.
Speaker 1:So those cases, those proxies were pretty awesome. And then, of course, eventually, we had, you know, DSL starting. Cost of frame relays and t ones came down, then DSL came out of the market. You know, 36 k DSL was like a you know, it was it was like, this is the fastest thing I've ever experienced in my life, you know, kind of conversations with people. And then DSL started getting faster and faster and faster.
Speaker 1:T ones got cheaper and cheaper and cheaper. Cable modems came out. Yada yada yada history of the Internet. So where else were we using proxy servers? Okay.
Speaker 1:So what this company was doing was it was taking in if you were filming a movie in, Czechoslovakia, you know, more than likely if it was a special effects movie, which all movies are, you had, some sort of effects company working and the big ones, of course, were ILM in San Francisco, but most of that industry was centered around Los Angeles or maybe you're in Weta Digital in Auckland, New Zealand. So you had to move data between one place to another. That was one example. Other example was then the special effects houses done work and the director is in this other country or the location and wants to be able to review the work that they're doing with the effects supervisor to say, yes, they like it or no, they don't like it or what changes need to be made or maybe it was an application around digital dailies. You know, again, these are this is now maybe more common in the in the market, but was very cutting edge when this came out.
Speaker 1:And there was a few summers every major summer blockbuster, you know, use this network in order to to move data. The trick here is when you're moving data across high latency links you run into a window scaling issue and you've experienced this yourself on your computer because you've taken and started to download something and you watch the speed on your download bar on your browser and it starts slow and it scales up to a point and then it stops at that point. And you'll look at this and you get really frustrated because you say to yourself, I know my network connection is faster than how much data I'm getting here. And the answer is it is. And what you're doing what's happening there is you are getting kneecapped.
Speaker 1:You're getting blocked. You are getting constricted by a really old artifact in the TCPIP protocol, which is the send and receive window size within the network stack. And this default was set at a time when Internet connections were really slow. It controls how much data can flow through it. It also controls the algorithm of how much data it starts with to send and then how it tests up to what its maximum transmission is because your computer has no way of knowing how fast its network connection is and how fast the connections are in between, like, here, you, your ISP, the whole mess of the Internet, and whatever the the sending system is.
Speaker 1:And so the way it does is it starts small and it keeps testing and growing until it finds its maximum. But your maximum is set by the algorithm by settings that you have in your system. Now you can take and you can override these settings and you can increase this in the world registry tax that would just go through and just arbitrarily, like, you know, increase these numbers by a factor of 10. That's not necessarily a great thing to do either because there there are some significant side effects and and negatives that come out of that for you, especially if you're dealing with all of a sudden now a network that's not performing behaving properly, performing properly, or is just slower and you've hijacked your network settings on your computer and told it that it's supposed to be really fast. There are some commercial platforms that you could go out and buy like a Aspera was one big one and Aspera worked around this by you would, you'd have 2 boxes on both sides of the link and you would send on one side would talk to the one box.
Speaker 1:This box would talk to this box. This box would talk to whatever else you're talking to. Right? And so it could accelerate the transfer between the 2 of them. And what the asparas were doing was they're just using UDP versus TCP.
Speaker 1:And UDP doesn't have doesn't have retransmit, doesn't have the testing, doesn't have this window sizing issue. So by converting from from TCP to UDP and then transferring between the asparas was basically like, you know, you remove the the governor. There's no speed limit. It just shoves as much as possible. And then, of course, you know, the engineers with Aspera had to build in a lot of fancy software to do, things that UDP wasn't designed to do, which, of course, is how you check some of your data transfer and make sure you're getting everything across it properly.
Speaker 1:So now what this company did that I was consulting for is we figured out how to build our own asparas, for lack of a better word. And what those were were just proxy servers. Again, this evil term can be a good term. And what these proxies were in each of these markets, So in Vancouver and Toronto and New York and in London, Australia, servers were put on place. And the servers connecting connected into the you know, had had net multiple network interfaces.
Speaker 1:1 that went on to the backbone, one that was facing the customer, facing the end user. And and now because we had these proxies deployed on this backbone everywhere, we could test and figure out what the network latency was. And so I was running software constantly that was was figuring out, you know, the latency on this backbone between point a and point b and point b and point c and point c and point d. All these different permutations to network. What was the actual exact milliseconds of latency?
Speaker 1:And the point of all this was to be able to then compute and figure out the bandwidth delay product. And the bandwidth delay product is just a, you know, simplistic math where you say, I have this speed link and this milliseconds of latency. And so, therefore, the window sizes need to be x. Right? So x plus y equals z, you know, kind of thing.
Speaker 1:And so you create your window sizing at z. And so that way when you would talk to the proxy server, low latency link, the end user's computer could size itself and do its own thing and everything was fine. But that proxy server then knew on its backbone link what window size to use. And instead of having that that download that status bar start small and can't come up to here and then cap, it would just start at full speed. It was just, you know, like a turbocharger or throwing nitrous or whatever you wanna call it, which is there and it was good to go.
Speaker 1:And, these proxies were a very inexpensive solution to this problem that created an end result. Now Aspera came out and was running at that time. But again, you know, this became a cost issue. I talk about this in a lot of different things. Right?
Speaker 1:So you can go out and you can buy a commercial platform off the shelf and you could spend a fortune on it, or you can build it yourself if you know what you're doing and you could save a fortune. So this company created a competitive advantage for itself because it was not using expensive off the shelf, you know, hardware from a manufacturer or from, you know, and licensing it. And then for every because in that case, if they were using Aspera, every pop they wanted to create would have required an Aspera. And as they wanted to push more bandwidth, they would have had a license more in Aspera, and their their cost would have always gone up. And what you want in your business is you want your cost to stay the same or to decrease as your volume increases.
Speaker 1:Right? You want that efficiency. You don't want, like, these one for 1, like, you know, you sell a new customer and your cost increases. You want your cost to stay here and you want your revenue to increase or you want your revenue to increase and your cost your unit cost to decrease. Right?
Speaker 1:So so, that's how we did that. Another hack that was really fun. I use the term hack, not in terms of, like, computer hacking with software, but hack in terms of, like, you know, tweak of an approach of conventional wisdom, contrarian thinking, right, in terms of hack. A customer that accidentally ended up doing business in China. And when I say accidentally, they had a an application SDK that got installed on cell phones via their software, and they noticed that all of a sudden they had a bunch of end user devices in China.
Speaker 1:China is a very interesting animal. First off, you have to have in country, representation. You have to have an ICP license. Your ICP license is based on the type of business that you're doing. Then based on the type of business, your intellectual property and your infrastructure is supposed to be inside of China.
Speaker 1:You can't move data inside out of China. There's all these rules and regulation and stuff that, you know, maybe other countries should be doing as well. I won't get into that too much that China enforces. So there's a lot of regulatory overhead with China, and there's also technical overhead with China. Right?
Speaker 1:So to go and take and put servers into China is very expensive. It's also complicated if your application isn't designed to run. You know, in this case, they were running almost all their application in US east 1. So to take and put a portion of that infrastructure in somewhere in China just to run the Chinese marketplace, there, you know, the the infrastructure, you know, you have maybe you have to redesign your application. You have a lot of engineering hours.
Speaker 1:So then you deal with, well, you know, the Chinese firewall. You know, the Chinese firewall really does a couple things. It absolutely does enforce policy from the Chinese central government. So what can and cannot be transmitted in and out of China gets implemented from the Chinese firewall. The other thing that happens, and this is a a product of the Chinese of the Chinese firewall, it's also a product of just the Chinese network reality of network links, is everything is always saturated.
Speaker 1:Everything, you know, there there's been this thing for, you know, as long as I've been aware of network engineering on a backbone for ISPs is some network turns up a Purion link with with, China Telecom or China Mobile or China Unicom or any of the Chinese networks. And let's just say it's a 100 gig, you turn on a 100 gig link and the link goes from 0 to a 100 gig instantaneously and saturates a 100 gig. There's so much latent demand and capacity there that you just can't keep up with it. So a lot of the challenge of dealing with Chinese eyeballs or Chinese moving data in and out of China is just the network links are always saturated. Right?
Speaker 1:This is why most of the solutions around private networking into China are just that. It's MPLS links in and out of China just that way you don't deal with the light, you know, the saturation of all these public network links. You know, forget forget all the other stuff. Just just sidestepping public interconnects, you know, saturation and solves a lot of your problems. Going into circles here.
Speaker 1:So going back with this customer. So this customer had an issue where now they had Chinese eyeballs app access in their application, and they were getting inconsistent performance to those to those applications, which, of course, inconsistent performance makes it very difficult to profile and to optimize performance. And And then you got pissed off people because their stuff doesn't work right, yada yada yada. And, we were going down the road of figuring out how to put infrastructure for them into China. What it was gonna take?
Speaker 1:What was the regulatory overhead? What was it gonna require for them? How were they established operations? How to get the application loaded and running what was this all gonna mean how much was it gonna cost business requirements regulation regulatory requirements aside we got to a number that it was gonna be on a minimum basis just bare minimal to get infrastructure turned up inside of China for them was a $100,000 a month. They were spending about $2,000,000 a month on AWS.
Speaker 1:So they're gonna have to spend 5% of that to bring up dedicated infrastructure inside of inside of China. But now, you know, you're looking at all of a sudden, materializing $1,000,000 plus a year in IT infrastructure an IT budget just out of nowhere. Right? I don't know what your budgeting cycles are like. But most people if you come to them, you say, hey, by the way, you gotta spend an extra you have to spend you have to increase your IT budget by 5% tomorrow just because that conversation never goes very well.
Speaker 1:As we were going down this path, you know, fortunately, we had a really really good relationship with this customer. Made a proposal of doing a test and doing a test in a manner that wasn't gonna be all or nothing or all in but massively asymmetric benefit, leverage benefit if it worked. And that that was just simply that we were dealing not with a that we were dealing with nothing more than just inconsistent latency, variability, and saturation of the network going into China for their application to work. And that they didn't actually have to go into China. They just had to deal with alleviating that issue.
Speaker 1:And what we did to alleviate that issue was we contracted with the Chinese networks who all land on the West Coast of the United States to interconnect and peer. And we took 10 gig circuits from those networks, and we put them into a data center. And in that data center, we put proxy servers. And those proxy servers had one network connection that was facing the Chinese networks and one network connection that was facing a direct connect. And back then, the direct connects were not universal, so we had to use an intermediary network that could then backhaul from the West Coast into, into Ashburn, Virginia in order to interconnect with interconnect with AWS.
Speaker 1:All of the ingress and egress traffic to and from China for this customer flew in, you know, came in and out. So it went, you know, China network, proxy server, intermediate network, Direct Connect, AWS, and back and forth. Didn't solve solve a latency issue. I mean, you're still dealing with talking about going from, like, China around the globe to Virginia. I mean, it's a lot of network segment.
Speaker 1:It's a lot of distance. But what it did do was it created alleviated the choke points on the network, created consistency and predictability of that network traffic, and it solved the problem. And instead of spending, you know, 1.2 +1000000 dollars a year to solve this problem, plus operational overhead to split their application, do everything else that would have been who knows what engineering distraction, what would have been who knows what. They spent less than $10,000 a month to put this proxy in place and solve the issue. So the trick here becomes, you know, and and the moral of these stories are, if you go to an engineer and you say, I've got this problem and I just solve it, a lot of times an engineer will solve the problem that you face them with.
Speaker 1:The challenge is actually understanding what the business is trying to do. And is there a different way to solve the problem? What's the end result that you actually want? The customer needed the last case, the customer needed, better performance into China. So that way their Chinese eyeballs could use their application that could generate revenue.
Speaker 1:Business does not care what way that actually takes place. Given the choice of spending a lot of money or a little money, of course, the business always cares and is gonna try to use the cheapest way possible. And our goal is to find and implement technology and solutions within the tech stack that gives leverage and the maximum value, you know, per dollar spent. So it would have been really easy to solve this problem by spending a $1,000,000 instead we spend a 100 k. That 100 k created a lot of leverage in that environment to then you know continue to grow the business serve that traffic and have a competitive advantage you know same example earlier with global proxies you know having having a leveraged competitive advantage versus going out and licensing having one to one cost This is where tech excels for your business and understanding where and how to apply tech to your business, not to solve a business problem, but to actually create additional leverage for you and, you know, increase margin, create more revenue opportunity, whatever you wanna call it.
Speaker 1:We can use all the fancy, you know, business mumbo jumbo terms. But at the end of the day, the fun things that we get to do is we get to create and craft solutions to solve business problems and create leverage for that business so that business can grow and excel so I'm ex Clark this is a quick thought I hope it helps you in some manner
