I am someone who likes to understand concepts through analogies. If I can’t get to analyse a problem using an analogy that everyone can relate to, I will try to refrain working on it. The corollary is that, if someone cannot given me an analogy for a problem or solution, I will be more inclined to think that they dont have a clear understanding of the problem at hand…Anyway, being in the networking world and talking all about traffic engineering for a living, it is very logical for me to analyse these problems using the real life traffic. I found some of the results amusing…:)
While we have figured out how to get the internet traffic to get faster and more reliably decades ago, we are still getting stuck in our regular traffic to work. As you all know, a given networking link is characterized by how much traffic it can carry (bandwidth) and how much time it takes to carry (latency). Reliability is a relative word and I dont think it has much relevance to my following analysis. The question now is, what is the bandwidth of a freeway? Well, we measure network traffic is bits per second. For freeway, let us assume that it is cars per second. We could later change that definition to be passengers per second. For now, assume that there is 1 passenger per car.
Let us do some math. At 65 miles per hour speed, and an average car length of 5 meters, the number of cars per second is about 5.72, we can approximate it to 5 (since the trucks and the minimum gap between cars should be discounted for fairness). If we have 4 lanes, this comes to 20 cars per second or 1200 cars per minute. The two sided nature of the problem is that, the traffic is really heavy only 2 times in a day for around 6 hours. Provisioning the road to account for the peak case is the obvious solution, but a bad one too. In the networking world, we call it bursty traffic. Let us say, we want to double the traffic in a given freeway, what are our options? The obvious ones are (i) Make the cars twice as fast (ii) Make the road twice as wide, change it from 4 to 8 lanes (iii) Accomodate 2 passengers on each car (iv) Make the car half the length. Knowing what we know, (i) & (iv) are not easy to do, (iii) is the equivalent of enforced car pooling and (ii) has a cost associated. We could have different priorities with high priority cars or vehicles being the ones carrying more passengers versus ones with smaller number of passengers which in turn can transport more passengers per second since the larger passengers are grouped into a single lane. We could have alternative modes like trains and hope that passengers would take trains instead of cars, in which case the problem centers around how many passengers we can transport per second.
Ideally, if we make a big enough vehicle that can accomodate all the passengers to a given destination city, that is the best we can do. I just checked up that BART service here in bay area can carry a comfortable load of 700 people in a 750 feet train (225 metres) at an average speed of 36 mph (considering stops at stations). Now, if we had enough trains to carry people around, the ratio between car-passengers/second and train-passengers/second is 20 versus 50 passengers. Only a 2.5 speedup and the extra wait time in station to get into the train and back. Again, we can try to optimize by double-decking the train since adding additional railway line can be quite expensive, assuming the rails can handle it. Also, having non-stop service can increase the speed by 2 or 3 fold which can give benefits too. Remember that, the more the wait time to get to a train, the latency increases. In some cases, the bandwidth can look great if we wait long enough to accomodate as many passengers as we can. But, the time to get to a destination will suffer terribly.
Now, if you would substitute cars with packets, passengers with cells (fixed size units which makes up a packet), transmission rate or capacity to bandwidth, the same kind of problems exist in networking and the same kind of problems are applicable there too. The parts that are easy in networking are that, creating wider lanes with high capacity is becoming increasingly easy and cost effective. The part that has always been difficult is to handle burstiness of traffic. Though there are many solutions, optimality is questionable. Another thing that is possible in networking is the use of a scheduler. If we exactly knew which routes were free and how many people want to get to a given destination ahead of time, we can allocate their paths for optimality. But then, when everybody is bursting in all at the same time, scheduler optimality is not guaranteed and that is still a problem. Well, that’s all folks. You have survived yet another round of my random rambling session…Congratulations!