WAN Optimisation and the motorbike fleet

Ian Yates interviews Steve Dickson of WAN optimisation vendor Riverbed, who cooks up a fascinating metaphor for the way data moves over the WAN.

Ian Yates: Steve what fits under the heading WAN Optimisation? It's all really about making the WAN go better isn't it really?

Steve Dickson: Yeah you're absolutely right and I often like to say that it's about trying to make the WAN disappear... to such an extent that everybody appears to be connected to the same local area network and more importantly within the same vicinity and even in the same city if you like rather than distributed around the country or around the world.

Ian Yates: Uh huh.

Steve Dickson: It's not entirely possible because if you are over in South Africa and you're having to send data over there you're going to have the journey time from here to South Africa but at the speed of light the journey time is not actually that great. The problem of course we have is the journey time is multiplied many thousands of times because of the number of roundtrips taken because of the way the application works and the way TCP works.

Ian Yates: Yeah.

Steve Dickson: So the nil effect of trying to send something from here to there courtesy of TCP and Bill Gates means it takes a hell of a lot longer than you think it would. I don't know how long this interview is going to last but I'll give you an analogy which I often like to use because I think it puts it very clearly into perspective for people. If you Ian and nine of your mates decided to go to Melbourne for the weekend, watch the footy, have a bit of a party and you all got into your cars and drove down how long would it take you? You know how long would it take you to get to Sydney down to Melbourne? 12 hours I guess if the road was reasonably clear. A little bit of congestion it may take you 14 hours or 16 hours or whatever.

Ian Yates: Mmm.

Steve Dickson: But you would be there everyone would hope within a day. However if the Bill Gates factor came into it you would all get into your cars and start your engines but then you would wait for a motorbike to go backwards and forwards 100 times first. The first thing that happens of course is we have this application of all chit chat and for something very simple like dragging and dropping a file it starts off with about a hundred pieces of chit chat that go backwards and forwards at the application critical level. So you're sitting there waiting patiently for this motorbike to go backwards and forwards from Sydney to Melbourne 100 times and when it's completed three of you get to leave. You all sit there waiting patiently for a motorbike to come back from Melbourne so they arrive so four of you can leave. Because the way TCP works is that it will send a certain amount of data and wait for a successful acknowledgement before it releases the next amount of data.

Ian Yates: Right.

Steve Dickson: And eventually all 100 of you arrive down in Melbourne and you think well thank heavens for that because we really need a drink right now. Hang on a second we just have to wait for a motorbike to go backwards and forwards another 124 times because back at the application protocol level we need to close off the operation of the data transfer and check that everything's been sent before we can say we've all arrived. That 12 hour journey actually takes a little over four months.

Ian Yates: If this is translating if it was human travel into the way data packets move?

Steve Dickson: Yeah so in...

Ian Yates: By the way we missed the grand final you know.

Steve Dickson: You've missed the entire season.

Ian Yates: And we probably missed most of the cricket as well.

Steve Dickson: So the crazy thing is that the journey time should be 12 hours and for each one of you when you went down, you took 12 hours but the problem is that the overall transmission time for all of you is over four months.

Ian Yates: Yeah.

Steve Dickson: That's exactly the same thing that happens with every time you try and access a document and opening a document is much worse. Opening up a Microsoft Word document off a network share there's over 500 steps. There'll be 500 round trips by that motorbike and so the time just builds up again. So to do what you do...

Ian Yates: Hang on that's not wide area that happens locally too doesn't it?

Steve Dickson: It does. It happens every single time you do it. The difference is that at a local level your latencies are microseconds, maybe a milliseconds or two but not much more. It's really when you get above five, ten milliseconds and upwards and by the time you hit 50 or 100 milliseconds the time really gets very, very pronounced and so something that would take maybe two seconds may take three minutes simply because of that round trip.

Ian Yates: Okay.

Steve Dickson: What we do is we remove a lot of the data. We spoof the protocol that it enters. Instead of a motorbike going backwards and forwards from Sydney to Melbourne you have two motorbikes, one going backwards and forwards in the car park at Melbourne and one going backwards and forwards in the car park at Sydney. In the way we adjust the TCP settings it's a standard based thing. I receive I think 13, 23 dynamic window scaling for TCP windows and it says basically you can increase the size of the window. In other words instead of three of you going down and waiting for a motorbike and then four all one hundred of you can go down at once.

Ian Yates: Right.

Steve Dickson: And one motorbike comes back at the end of it.

Ian Yates: Yeah.

Steve Dickson: So by doing these things you remove the number of round trips and then that effect is you get closer to that 12 hour transfer time.

Ian Yates: So what maybe it takes a week instead of four months?

Steve Dickson: Yeah it might take a week. It might take two, three, four days but it's not going to take four months.

Ian Yates: Yes.

Steve Dickson: And similarly what we see is that a circuit say to Perth which has 60 milliseconds so therefore you'd think the transfer would take 60 milliseconds. It doesn't it ends up taking two minutes but if we bring it back down again so you save two or three seconds than we are close enough to landline performance if you can't really tell the difference.

Ian Yates: Yeah.

Steve Dickson: And that's the holy grail and the challenge is being able to do it across all of the applications that we run across that wire and to be doing it incredibly fast and to be doing it with 100 per cent accuracy and reliability every single time. Because if you ever try to do what you do and at anytime it ends up corrupting some data or causing some data consistency issues, well you're history. Nobody's ever going to trust you again. You can never ever afford to cause a problem in that data transmission and so you've got to be very fast, effective across all applications and be able to guarantee 100 per cent of the time that you will never ever cause an issue with the data.

Ian Yates: Right.

Steve Dickson: And on top of that you've got to be able to drop seamlessly into every IT environment that exists out there without requiring any changes to be made or a minimal number of changes if there are any at all and that any changes that are made after you've gone in don't require you to make any changes to your check. In other words they've got to adapt automatically to the changing environment around them. It's only when you do all those things that you can then say you've successfully arrived at being a true optimisation product.

Ian Yates: Right.

Steve Dickson: And once you've done that, once you've achieved that goal, then what? Well then the company has just managed to remove an obstacle and the reason they want to remove that obstacle is not because they want things to go blindingly fast, well they do but that's not the business reason usually. The business reason is that because they've now got that they can consolidate file servers, they can centralise backup, they can centralise storage, they can remove things like technology, like Citrix out of their environment altogether and they can go back to having standard SOE where everybody appears to be connected to one giant local area network. So that is the holy grail because that gives them the significant cost reductions, deductions in support, deductions in risk and audit and compliance and governance. It increases business continuity and all the other things they're trying to achieve.

Ian Yates: Right.

Steve Dickson: And our job in all of this lot is to just remove one of the obstacles which is the WAN performance.

Ian Yates: And if you've got a situation where a small business might be using one of those ADSL plans, could a product like yours have any affect for them or would they have to upgrade?

Steve Dickson: Yes well of course the DSL plans really are in the megabit range. You know you can join it together and probably get whatever size you want. The problem with a DSL circuit is the little box on the end of it called a DSLAM.

Ian Yates: Yep.

Steve Dickson: Now the DSLAM adds 25 milliseconds of latency.

Ian Yates: All by itself?

Steve Dickson: All by itself. So yes you get fast transfer speeds but you get unfortunately a significant amount of latency added to the transmission time and it's latency that's a killer. So and then of course with the non-business grade DSL it's also a contention based or congested circuit so you don't always get guaranteed performance. The latency for transmission varies based on load and a whole bunch of other things kick in.

Ian Yates: Right.

Steve Dickson: So it's not unusual to find sometimes the latency on DSL needs to go 50, 80 milliseconds and at that level you're experiencing some really quite substantial delays.

Ian Yates: Yes not that is a common sort of speed even with a couple of cable Ethernet modems you probably won't get much better than about 60 milliseconds.

Steve Dickson: Correct.

Ian Yates: So what your products probably couldn't do much for that or...

Steve Dickson: Yeah absolutely. It just makes such a difference it's sort of embarrassing.

Ian Yates: Oh really even just something like that on a consumer grade DSL, something in one of your Riverbed toys could actually make a noticeable difference.

Steve Dickson: Yeah.

Ian Yates: Oh really?

Steve Dickson: Absolutely but the time when we would make the least amount of noticeable difference from an end user perspective at least would be an organisation that say has several branches around CBD Sydney connected via a land link. So very high grade fibre perhaps or...

Ian Yates: Paid for it themselves, own it all.

Steve Dickson: Yep and the latency is sub five milliseconds. They've got 100 megabit per second bandwidth and then really we'd make a marginal difference simply because they've already got a local area network connection that is local area network performance. So what we do is reduce 80


Read more on WAN performance and optimisation