I'm not sure what you are asking about, MPLS, or Before MPLS.

"(Before MPLS switches allowing larger packets were mainstream and

Many current Layer 2 Switches support MPLS. Example is newer CISCO switches, since Cisico developed MPLS. Any MPLS enabled switch supports the larger packets because MPLS uses larger packets. I do not know exact model numbers off top of head of all manufacturers that use MPLS but there are a lot, that jumped on the MPLS bandwagon, as we don't use third party routers yet, we use our own based on Linux. Some of the Cisco routers that were cost prohibited 5 years ago, are now much lower in cost. This is not jsut with a specific line, but pretty much all across the board with all products in the networking industry where price drops every year as new faster products come out. 6 years ago we decided to use our own Linux Routers, and today many people ask us why we chose that option. The reason is that todays technology did not exist 6 years ago at the price it can be had for today. For example Mikrotik today is a super feature rich unique product that has evolved to do ALMOST anything someone would want to do. (can't do cipe). But 6 years ago it was not so special, and our product out featured it in many areas, justifying the code writing. Our product did not evolve to that level, because we decided to stay in the WISP business not router manufacturer business. But to date, I can partner/peer with any ISP in the country, over any type of Layer3 connection in a secure manner, and deliver full 1500 MTU between us, because we use Linux routers that support CIPE. Thats one of the reasons that if I chose a third party Linux Router other than ours, it would be IMageStream, that allows CIPE tunnelling, apposed to StarOS or Mikrotik.

In case you are not familiar with CIPE... Cipe basically splits packets that exceed 1500 byte, and then reassembles them at the end of the tunnel, so they are not fragmented. There is a slight penalty to this in through put, but not significant, no more than 5%. The degregation is of course by adding an additional header for the second have of a split packet. But that only happens when the packet exceeds 1500 bytes. Most Internet packets are not full 1500 bytes in size.

The bottom line is todays clearly lack in their ability to handle QOS and Bandwidth in a way that is optimal and accurate for many Wireless network designs (nested PtMP links, Mesh, Star within star, redundant path, etc). Technically todays available routers are once again outdated and incapable for today's need because of it. As a result, we are back in the programming room. Not because we want to be, but because there is not a product out there to do what needs to be done. For example, I'd like to see one of the major software vendors like ImageStream, Mikrotik, or STAR OS, take over maintenance of the OPEN source MPLS and include it on their routers. One of the things we are investigating today is, can off the shelf CISCO type routers (any manufacturer) now do what we want, at an affordable cost? We are getting close, but so far that has not been proven possible.

We have a situation today, that as a service provider we MUST face the reality of finding a better method of managing QOS and bandwdith management. The reason is one reason only, "VOIP". In tier 1 markets if you can't deliver QOS adequate for VOIP end to end acorss your network, you lose the large multi-site deals. We don't have an issue today because we are undersubscribed. We also have temporary methods that could buy us a year or two, such as filling in with more dedicated PTP links to increase capacities, where possible. Or we can start adding more Fiber links at more cell sites to throw capacity at it. But the problem area is in nested PtMP links in common aggregation points. Smarter allocation of bandwidth is required. There becomes a real cost justification to make smarter software to prevent the pre-mature expendatures of a LOT of hardware network wide.

To solve QOS, either there must be a way to provision every customer at every hop of every possible path they may take, or label the packet so a router knows how to handle it, and routers need to be aware of every available amount of bandwidth on each of its connected paths, or for that matter which complete path has the average most available bandwidth, so that it can stay delivering the client across that path instead of prematurely swapping paths that could cause out of order packets. And what happens if the link speeds decrease, due to modulation change or packet loss and UDP traffic is being sent? Things like HTB or equivellent have you hard set the backbone speed for its bandwdith management decission making.

Many of the MTU problems can be solved with Layer2. But can an ISP always get a Layer2 connection from its two points? For example from DC to California?

My prediction is there will be one of two things that happen the next two years. 100mbps and 1GB wireless products will become affordable to solve the problem with raw speed, or major feature adds will happen on Routers made for wireless provider's cell sites. This QOS problem is not something solveable from the Radio (bridge) manufacturers themselves, it has to be solved at the router software level.

I call the needed technique "adaptive bandwidth management". Because bandwidth management logic will need to dynamically change based on the conditions of the links and network and type of data. If you put your mind to it, its chaotic, so many possible random changing variable to effect the logic. Part of the solution is routing protocols designed to spread bandwdith equally across multiple link paths, so you can increase capacity by adding radios not just by increasing capacity of them, which may not be possible in noisy long range links. The current load balancing type protocols are not adequate, as its not likely the paths will be going to the same destinations, to completely solve the problem. And there needs to be a way to tell in real time which path data tends to take, so troubleshooting of network performance problems is managable.

The logic behind MPLS is, label each packet with a priority, and then pass them based on priority. And the amount of banwdith you have is the amount of bandwdith you have period. To do better than that, the option is to increase capacity/speed when your average capacity starts to get saturated. So MPLS is a good structure for making the best of what you got. But MPLS does not help you gain more capacity. Smarter routing is needed to take advantage of the full capacity of all your links. The idea is not to have links sitting idle when one link is getting maxxed out and slowed down. Even if the path is longer, it may be faster if uncongested.

The advantage Fiber carriers have is that the capacity is unlimited more or less, and sending the data From Dc to NewYork and back to DC again, is no sweat if its what the routing says to do. With Wireless, thats not the case. Every additional wireless hop is a change for packet loss or runnning into a degraded interfered with Link. LOS issues may prevent direct paths between perferred sites. Distance and capacity is limited. So again, the routing needs to be smarter than what was adequate for fiber networks.

Just my 2 cents on the topic.

Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband

----- Original Message ----- From: "Gino A. Villarini" <[EMAIL PROTECTED]>
To: "'WISPA General List'" <wireless@wispa.org>
Sent: Tuesday, August 01, 2006 9:38 PM
Subject: RE: [WISPA] frame size and fps - Mikrotik large packets

"(Before MPLS switches allowing larger packets were mainstream and

Where ? care to share ?

Gino A. Villarini
Aeronet Wireless Broadband Corp.
tel  787.273.4143   fax   787.273.4145

-----Original Message-----
Behalf Of Tom DeReggi
Sent: Tuesday, August 01, 2006 4:23 PM
To: WISPA General List
Subject: Re: [WISPA] frame size and fps - Mikrotik large packets


Thanks for the clarifications from your engineer.

The only comment I disagree with is....

The proper VLAN aware drivers show 1500 MTU for both the underlying
and the VLAN interface but it treats VLAN packets with caution, so as not

truncate or drop them because of their longer size.

If that's true, then it isn't a "proper VLAN aware driver." The MTU should

set correctly and not just show 1500 and use something else.

My statement was just bringing up that the MTU is for the size of the packet

before VLAN tags were added, and VLAN header bits are added on top of the
existing full size packets. The reason for this is that we guarantee to
deliver 1500 MTU to the consumer, and we want the setting to show what the
customer expects to get. If we tag it with VLAN for our own use, we must be
able to pass the higher size packet, and strip the VLAN off before
delivering down to the client on the other end.

Opinions on this depend on what the provider is trying to do with the
router. The needs as a customer premise router is different than the needs
of a ISP transport provider router.  The way StarOS does it, to shring the
MTU, is appropriate for Customer premise routers, and it would make sense
under that circumstance for the MTU setting to reflect the new MTU size that

the customer would see. But in our application as a transport provider, our

cell site routers want to appear transparent, to any application the
consumer may want to use. Its standard that Ethernet is limited to 1500 MTU,

and the Consumer should have not problem working around that, and when they want to lower their own MTU. However, as a provider, we never have a need to

lower an MTU, as lowering an MTU would compromise the service delivered to
the consumerthat would expect to receive 1500 MTU capabilty. The problem is

not all ethernet devices pass IPSEC higher MTU. Its why it ended up not
being a preferred method for tunneling across our network or other's
network, without compromising delivery of 1500 MTU to subscribers. Thus the

reason we switched to CIPE tunneling as our standard tunneling method. And
major reason for selecting Linux based routers.

I'd like to add, that I believe ImageStream supports CIPE tunneling. One of
the disadvantages of Mikrotik and StarOS, is that they do NOT support CIPE
tunneling. It was one of the reasons we built our own routers 5 years ago.
(Before MPLS switches allowing larger packets were mainstream and

Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to