Application Level Routing in a Mesh Router? 23
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 ?"
possible (Score:2, Informative)
In a word: (Score:3, Funny)
buffering......
buffering......
buffering......
[garbled]
buffering......
[unintelligable]
<28% packet loss>
[NO CARRIER]
Re:Anybody finds this interesting? (Score:3, Insightful)
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!
Re:Anybody finds this interesting? (Score:4, Informative)
If you control the network there are a lot of possibilities, including MPLS, but for a single user on a network there is not much that can be done as anything that is broadly accepted so that "it works" can be used by everyone and the problem is just reduced back to bandwidth contention.
If bit-torrent becomes to slow compared to VOIP people WILL encapsulate it as some kind of VOIP protocol in order to use the faster network.
If VOIP quality is good too many people WILL use it instead of regular telephone till the VOIP quality becomes poor.
Commoditize the bandwidth (as my manager keeps telling me) and charge people for the quality of service they need. Variable price sounds scary compared to "all you can eat DSL" but it is the only model that will provide a service of the quality people need by charging what they are willing to pay.
As long as the customer has choice over DSL provider it will be best for everyone as DSL providers get best return on best bandwidth utilisation and customers only pay a premium for highly contended service types, which stimulates provision of more service (to cash in on those prices) which in turn reduces the price.
So you poor Americans stuck in cable-only DSL areas really really really need to write to your representatives and get competition opened up in your cable areas.
Sam
I maybe talking through my hat, but it makes sense to me.
Re:Anybody finds this interesting? (Score:4, Insightful)
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
Re:Anybody finds this interesting? (Score:2, Interesting)
Re:Anybody finds this interesting? (Score:1)
Re:Umm.....? (Score:1)
Oh, never mind.
RSVP (Score:2)
Re:RSVP (Score:3, Interesting)
While it is an interesting excersize - it is far from prime time. First you have the overhead of extra packet scheduling (and making sure that each RSVP'd stream stays within its reservation) - then there is the whole problem of what to do with packets that fall outside the reservation. Lets not even get into the policy questions on how a router decides if a reservation should be honored or not (much less who to charge for the bandwidth commitment)
All in all
Sandvine PTS - Probably overkill... (Score:3, Informative)
Sandvine PTS [sandvine.com]
Slightly more technical description of services provided. [sandvine.com] Notable quote: "QoS policies can be set for latency sensitive applications like VoIP and gaming."
If you try to read through the buzzwordese it might actually make sense. Although, I think this is probably overkill for what you want.
Off-line Tool (Score:2, Funny)
Not a trivial task... (Score:1)
This technology already exists.... (Score:4, Insightful)
Re:This technology already exists.... (Score:3, Insightful)
Re:This technology already exists.... (Score:1)
Second, bittorent is no good for streaming technologies (live video/audio, gaming, etc').
In this case, bittorent doesn't really apply. However, I agree that intelligence is easier and cheaper to impliment at the application layer.
Let's add some complexity... (Score:2)
I ask because it's what car's and PDA's are going to use to route packets through their peers to their access points.
Sorry, but it's very relevant.
To get your answer, first understand the question. (Score:5, Insightful)
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.