Jumbo Frames and microwave vendors

[ankarb]

​Do you know microwave vendors who support Jumbo frames?

Also, how they solve the QoS problem when they send together jumbo frames and real-time traffic to a low capacity link (e.g. 100Mbps link)? :confused:

Thanks in advance

[harrypotter]

You can increase the MTU size 1500 to support jumbo frames

[ankarb]

You can increase the MTU size 1500 to support jumbo frames


Thanks for the answer but the question is who supports what (of microwave vendors).:confused:

[mike]

Here you can find a little more information from ceragon Backhaul solutions.

http://www.ceragon.com/files/Ceragon%20-%20Jumbo%20Frames%20-%20Technical%20Brief.pdf

Jumbo Frames are not recommended for QoS Purpose (Except the case of Implementing MPLS where is required 1544Bytes instead of 1500). Jumbo frames are mainly used for transfering large files already stored in a server and not for real time applications.

Mike.:cool:


​Do you know microwave vendors who support Jumbo frames?

Also, how they solve the QoS problem when they send together jumbo frames and real-time traffic to a low capacity link (e.g. 100Mbps link)? :confused:

Thanks in advance

[ankarb]

Here you can find a little more information from ceragon Backhaul solutions.

http://www.ceragon.com/files/Ceragon - Jumbo Frames - Technical Brief.pdf

Jumbo Frames are not recommended for QoS Purpose (Except the case of Implementing MPLS where is required 1544Bytes instead of 1500). Jumbo frames are mainly used for transfering large files already stored in a server and not for real time applications.

Mike.:cool:

I understand the Ceragon explanation but in the case when Jumbo frames need to be supported they need an external router (!!!) to fragment them. I know that other vendors (I think E******* Minilink but also others) support Jumbo and my question is how they handle the QoS issue that Ceragon mentions in the technical brief.:confused:

[byja]

Yes, Ceragon's IP-10 does not support jumbo frames, only "baby" jumbo frames, which are frames a bit larger than standard 1518 bytes (up to little bit over 1600 bytes), enough to accomodate MPLS frames and similar.
But this is only one radio in the portfolio, every other radio in the porfolio like IP-10C or IP-10Q, or Evolution (ex Nera radio) support 9600 - 10240 bytes eth frames.
So far, it's handled in a traditiona manner, if you start transmitting big frame, you have to wait till it's transmitted, which can take some time on a low capacity link. Let's say with a link of 100 Mbps capacity, and with 8000 FPS, it's around 1550 bytes per radio frame, so it can take several radio frames just to transfer one eth frame. With IP-10 family there's an option to build an optimized channel for let's say PTP packets so they're always transmitted even if you have a big frame going over. But that's only one out of eight queues, the other have to wait. Guess you'll always have to put jumbo frames into best effort, and not send them unless all other queues are empty. One of the standard demonstrations I did during training sessions is to show how big low-priority frames can choke hi-priority small frames when fair queueing/WRR schedulling is applied.

Think that R&D is working on a solution for this problem, so I expect in next software release it's gonna be possible to bypass large packet going over radio to avoid this congestion and significant delay.

But I've said this lots of times, large packets and microwave simply don't go hand in hand, for many reasons. What sort of application requires jumbo frames anyway, and would you deploy MW link for this application? Have you seen anywhere a MW link carrying jumbo frames, cause I haven't so far. We're aware of 99% of roles for MW link, and it usually does not require 9600 byte frames, so in my opinion it's kinda pointless to focus your research on improving performance for 1% of the applications.

[simog72]

dont worry people... if Ceragon do not transport jumbos (..i mean DROPS jumbo frames)
all other vendors do now, and not in next release

i'm sure about E*******, huawei, SIAE upto 9,5k or 10k in split mount and FO portoflios devices

if i should choose..

i will buy a jumbo frame capable MW

please Ceragon guys here.. dont take too much personal
:D

for stack problem metioned for queues the most advanced vendors are using the "frame fragmentation" techincs

PS: i m smiling on minijumbo definition but it s ok :D

[ankarb]

dont worry people... if Ceragon do not transport jumbos (..i mean DROPS jumbo frames)
all other vendors do now, and not in next release

i'm sure about E*******, huawei, SIAE upto 9,5k or 10k in split mount and FO portoflios devices

if i should choose..

i will buy a jumbo frame capable MW

please Ceragon guys here.. dont take too much personal
:D

for stack problem metioned for queues the most advanced vendors are using the "frame fragmentation" techincs

PS: i m smiling on minijumbo definition but it s ok :D

Hi simog72,

could you mention which vendors support "frame fragmentation" functionality? Do you have any relative information?

[mike]

@simon72,

I put the link to the ceragon white paper in order to explain technically how jumbo frame works in a particular vendor. At the moment there is not an standard definition of Jumbo Frames for MW links. And I know that not only ceragon is doing research about this topic, but it was an example. Even if I have heard from others vendors Like E******* , Huawei, Harris about the support of Jumbo frame on their equipments, I don't have any technical document to support this. So, stop smiling and start sharing the docs from those vendors that you are sure they support jumbo frames. Just mentioning the vendors is not enough if you don't have any documento to support this. Also, don't share a brochure.

Mike:cool:


dont worry people... if Ceragon do not transport jumbos (..i mean DROPS jumbo frames)
all other vendors do now, and not in next release

i'm sure about E*******, huawei, SIAE upto 9,5k or 10k in split mount and FO portoflios devices

if i should choose..

i will buy a jumbo frame capable MW

please Ceragon guys here.. dont take too much personal
:D

for stack problem metioned for queues the most advanced vendors are using the "frame fragmentation" techincs

PS: i m smiling on minijumbo definition but it s ok :D

[simog72]

I told U..dont take too much personal
just use opinions (tech based i mean) for improve product, instead of pubblish a lot of usless paper to support a ulsees theory
in anycase:
why if "At the moment there is not an standard definition of Jumbo Frames for MW links." in some product Ceragon support Jumbo and in the most important IP10 no??
why u think that for a MW link u need a different Jumbo frame definition compared with other network elements??


i dont need white paper to undestand that jumbo frame have to be NOT DROPPED
go and have a look at HUWAEY 9xx series , E******* CN series , SIAE ALFOPlus and ALS series

all that vendors support jumbo starting from years ago


start thinking with your brain please dont base ur opinion on marketing papers or marketing "want to be " viral Movie(if u are a normal user)
if u are a Cergaon guy please ..we undestood you poisition ...calm down

[simog72]

Hi ankarb

the concept is :
if u receive a jumbo frame "Best effort" or "low priority" , the system can stop to serve this jumb and freez the ingress in to the radio buffer and start immediatly a high priority Frame delivery .B
asically u dont need to wait the servant (radio transmitter buffer) finish to send jumbos (10k ex..)
U can freeze the jumbo delivery, start and finsh the Higher priority delivery and then start the jumbo again (from the point it freezed before)
this optimize the delay experieced from sync signal (for exemple)


i hope this helps

PS this is quite a popular appraoch in MW modern architecture