Slashdot Mirror
Application Level Routing in a Mesh Router?
faisaladeem asks: "Are there such mesh routers that can re-route the traffic based on QoS? (I'm not talking about traffic shaping) For example, if data rate of a video stream decreases due to an increase in congestion along the path then the router will re-route the stream dynamically to a different path to ensure the QoS for the video traffic. Since a mesh network has many paths or routes, it can be assumed that a less congestive path can be found if the existing path becomes bandwidth constrained. I heard that MPLS supports this kind of functionality? Secondly, can a router estimate the latency/bandwidth on a specific route ?"
I do! It's quite close to the research area for my PhD! I'm looking at this kind of thing, but from a link-layer perspective. I'm not very far into it, but this is big stuff.
Residential area networks with fat broadband connections are great uses for this stuff. How about routing VoIP through one reliable connection, whilst sending all bittorrent traffic (and other delay-insensitive traffic) through the other connections? This would be a boon for reliability, too!
Sure, it's an interesting question, but in what environment does your mesh network exist?
To my mind, the most compelling situation for a mesh network is a multitude of nodes requiring internet bandwidth from the few nodes that have internet bandwidth.
The situation you are suggestion is that the application can discover from all the edge and in between nodes if there is a better route to a better internet-connected node to provide that bandwidth.
The answer may be "yes" but unless all the other bandwidth consuming apps at other mesh nodes co-operate, flip-flop-ing of the route is more likely to occur as other mesh nodes select their routes according to other rules, and cause congestion on the new route. (Unless you are the only one online at that time of night)
To avoid this there does need to be an arbiter of bandwidth, this could be done jointly by all apps (fat chance) or by the internet connected nodes which recognize the video stream or other request mechanisms from the streaming client and then use traffic shaping or other means to reserve enough bandwidth.
(Unless there is an abundance of internet bandwidth you are eventually going to be talking about throwing some of someone's packets away in the end)
Talking about re-routing is a red-herring as far as the solution goes, and presumes there will be an edge mesh node with enough bandwidth.
To illustrate; take the general case and presume some encapsulation protocol by which all the internet connected edge nodes are used as some distributed big pipe and can all have their bandwidth used to full capacity and you'll see that it just becomes a problem of reserving enough bandwidth for the stream. Going back to your specific case we just need all the bandwidth to be via one node.
So... let the internet connected nodes be able to recognize time sensitive traffic and prioritize bandwidth for these with some per-client-host rules to stop some clients hogging it all day. Now you are no longer talking about re-routing based on QoS but just plain routing based on QoS because once the route is chosen you get the neccessary bandwidth reserved and wont need to re-route.
Of course beware of hacker-type neighbours who start encapsulating their kernel mirror sessions over video stream protocols or the like - and so you see the simplest way is to charge a slight premium for better quality un-interrupted service.
Where bandwidth is scarce, sell it to the highest bidder and the profits will encourage the provision of more bandwidth.
Which brings me back to the start, I thought that mesh networks mostly existed where bandwidth (or internet conenctivity) is scarce, so any solution will only solve your problem indirectly by raising interest (and price) of this newly convenient streaming bandwidth, till someone providers a better and cheaper connection.
There are companies that produce such dynamic bandwidth management boxes (I'm sure if you ask me I'll tell you one) which help users get the best service from their connectivity providers, who in turn get the best price for the bandwidth they provide.
Best, meaning the bandwidth is more fully utilized, and paid for.
BTW, all I have done is reduce the problem from re-routing to routing based available bandwidth, but I would hope that this is something mesh networks have been able to solve?
Otherwise I think IP6 and SCTP protocols also will offer solutions to your problem (re-routing) presuming you can get enough continuous bandwidth at all, but I don't think they are used much for streaming commercially at the moment.
Sam
blog.sam.liddicott.com
Try Bittorrent... Seriously. It's one of the few applications that can route around congestion, because it takes bits of a file from various locations. Hence, some will have less congestion than others. And it will balance the remaining download automatically to congest as many paths as it can. Other swarming technologies should be capable of this also - I know some people who were working on just such a project a long time ago, which involved distributing files and applications across a swarming network, although they never got the vendor capital they desired and so canned the project. You can also write applications that do this dynamically. Set your routers to provide path differentiation (not difficult - most routers can handle this, based on policies) and determine a method to distribute load based on packet loss or receive rate and differentiate path with a swarm based algorythm. Of course, that's purely at the application level. At the lower network level, you need to consider that it's really not a good idea to let routers decide how to do this for themselves. Other than prioritisation based on TOS or similar, routers are much better to keep routing at a simple level. It's better to build in the intelligence at the application layer rather than the network layer if possible - Regards David
Enjoy science fiction? "Turing Evolved" - AI, Mecha, Androids and rail-gun battles. What more could you want?
Do you control the mesh of routers? Are they mesh routers (wireless type)? or are they many routers with connections to each other (deployed in a mesh)?
I think you are asking the wrong question. You may need QoS for applications. You may need a mesh for high-availability or redundancy or efficiency. You probably don't need to conflate the two.
QoS is to help in situations where bandwidth is used up. It drops, queues or buffers non-important traffic and forwards higher priority traffic first. If the network is solid, QoS is most helpful when bandwidth is used (or at least approaches capacity).
Most routing protocols can incorporate bandwidth, delay and other network indicators: EIGRP does and OSPF can be configured to do so. You will need a routing protocol if you want to manage a "mesh of routers" without too much administrative pain.
And now add policy based routing. You can combine a routing protocol with policy based routing to route high priority packets over a prefered network route, but if that route goes the protocol can route them another way.
A routing protocol gives you redundancy and multiple paths (and the ability to take advantage of multiple paths). QoS avoids congestion, bandwidth and latency problems.
_
So if you have end to end QoS and routers with a capable routing protocol and maybe some policy based routing, your problem is fixed.
But you asked about mesh routers (like firetide wireless?)... and wireless really doesn't have QoS standards- wireless QoS is kinda all proprietary now. So my best advice is:
You should check with your sales engineer for your networking gear, if they can't answer- find a different vendor.
I know several CCIE's who can answer this type of thing in their sleep.
-A
Oh and if you are asking this question and seriously positing MPLS as an answer, then you haven't done your homework. MPLS is not for wireless. MPLS is not something you implement or buy for your network- it is generally for carrier networks. Carriers can offer you some type of hand off and carry your traffic over an MPLS based network- but that won't fix your network, just traffic over the wan.
If you posted more specific info, it would be easier to point you along in the right direction.
And yes, this type of question is interesting to me, but this particular question is not conceived well in my opinion. And yeah, I do this stuff for fun and work.