I'm not sure what you are asking about, MPLS, or Before MPLS.
"(Before MPLS switches allowing larger packets were mainstream and
affordable)"
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'" <[email protected]>
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
affordable)"
Where ? care to share ?
Gino A. Villarini
[EMAIL PROTECTED]
Aeronet Wireless Broadband Corp.
tel 787.273.4143 fax 787.273.4145
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
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
Jeff,
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
interface
and the VLAN interface but it treats VLAN packets with caution, so as
not
to
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
be
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
affordable).
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
--
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
