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 ?"

Comments

possible

[Kaamoss]

I think there ar a few routers out there capable of something like that. Check out http://www.zytrax.com/features/qos.htm look slike it might be what you're looking for.

LOL

[Anonymous Coward]

Uh, no. There isn't. Nothing to see here, please move along.

In a word:

[Anonymous Coward]

Yes. You are looking for a

buffering......

buffering......

buffering......

[garbled]

buffering......

[unintelligable]

<28% packet loss>

[NO CARRIER]

Anybody finds this interesting?

[int19h]

Okay, I admit that I find several other areas more interesting than networking, so I'm biased.

But I still can't help wondering; are there anybody here that really finds this question interesting? :-)

Re:Anybody finds this interesting?

[XoXus]

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!

Re:Anybody finds this interesting?

[samjam]

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

Re:Anybody finds this interesting?

[samjam]

As I understand it the mesh network makes use of multiple uncoordinated internet connections to provide internet connectivity for the nodes of the mesh. Although the edge nodes may co-ordinate with eachothers, the internet connections may be with various providers in various address ranges making it generally too-late to re-route once a stream has begun.

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?

[flipper65]

Actually, MPLS would fit the bill here quite nicely. It allows you to specify ToS in an external label so that the routers do not need to peek at content to make routing deciscions. This makes for very fast routing deciscions. Keep in mind that you will have to support QoS edge to edge and once a packet hits an egress point to the public internet, boom, the QoS and ToS bits are stripped away. You might want to look at products from Riverstone, Alcatel, Seimens, and last but certainly not least expensive, Cisco.

Re:Anybody finds this interesting?

[int19h]

I don't see why my comment was modded Troll, when it produced such fine answers as the two that was kind enough to answer my question. Oh well.

Umm.....?

[The Shrewd Dude]

Wow, that's beyond my level of geekiness... do I get to stay on Slashdot?

Re:Umm.....?

[FLEB]

You're new here, are'n...

Oh, never mind.

RSVP

[lw54]

Couldn't you use the RSVP protocol to avoid the problem all together?

Re:RSVP

[MerlynEmrys67]

Have you ever run an RSVP enabled network ?

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 - over provisioning is still your friend

RSVP MPLS-TE

[Anonymous Coward]

I guess that PATHs dont become CONGESTED but interfaces do it. Having a LSP end-to-end you could manage it based on several things, may be using MPLS-TE, may be using some MPLS EXP bits for you CoS and then make the routing based on that information. You could trying with Fast-Reroute and Node/Link protection, if some link goes the LSP is re-computed thru another interface/router. dont try this on cisco :). Juniper rulez

Sandvine PTS - Probably overkill...

[JFitzsimmons]

Sandvine PTS

Slightly more technical description of services provided. 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

[Zoky]

Another idea. try getting your Data Rate Information using SNMP, if the data decreases, modify your route advertisement thru another provider.

Not a trivial task...

[Vlad_Drak]

.. to peek into the app laver to determine the content-type, track the connection at layer four, and actively monitor the throughput, and if you want to play with BGP at your public egress, you have a complicated system. Assuming that you're talking about a WiFi mesh, you'd need a specialized ASIC or a fast processor, and a lot of memory in the wild. You'd run into power or cost barriers if you deploy logic like this into the actual mesh, not to mention managing the mesh control messages. You don't want that obnoxious Baker kid's MTV Jackass stream to impact the Jone's NPR stream four blocks up. Terry Gross would not approve.

This technology already exists....

[GrpA]

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

Re:This technology already exists....

[dave1g]

I think that your solution solves his problem by saturating the entire network, bringing it to a low avg but possibly a best worst case than he currently has.

Re:This technology already exists....

[Vorondil28]

First, to use bittorrent for file xfers, the files would need to be in multiple locations around his network.
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...

[bergeron76]

I feel bad making this equation more complex than it should be, but what about AODV routing (On Demand Vector Based)?

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.

[agristin]

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.

Sad and sadder

[Anonymous Coward]

Watching Slashdot try to answer a networking question is like, well, watching Slashdot try to answer any technical question.

Hint: the wording of your question shows that, should someone reply with a correct answer, you won't be able to discern it from the hundred wrong ones and the eighty not-even-feasable ones. Hire a consultant or start reading reliable sources.