Solved: Delay while using data transfer via MGX

Rajiv Dasmohapatra · ‎12-29-2009

Hi folks,

I have two routers connected via two MGX as the diagram given below.

PC1 <--> R1 <--> MGX1 <--> MGX2 <-->R2 <--> PC2

The concern is while transfering the data from PC1 to PC2 (say FTP, etc), I find a huge delay: say about a minute to transfer a 10 mb pdf file.

The average latency between the two routers is about 20ms.

Could anyone provide any help on this.

thanks,

Rajiv

Giuseppe Larosa · ‎12-29-2009

Hello Rajiv,

SAR happens with any type of ATM link:

the process is that an IPv4 packet is placed inside an LLCSNAP header and then into an AAL5 PDU (enc aal5snap under pvc config is typical and default)

the resulting AAL5 PDU has to be sent as ATM cells.

on the other end the ATM cells have to be received collected to reassembly the sent AAL5 PDU, then the IPv4 packet is extracted and routed out a LAN interface.

This happens on the routers with an ATM interface.

so the fact that you are using ATM E1 doesn't change this.

Hope to help

Giuseppe

View solution in original post

marikakis · ‎12-29-2009

Hi,

10 Mbytes = 10 x 2^20 bytes = 10485760 bytes of application data

If we ignore TCP/IP overheads and AAL5 and suppose those application data fully occupy cells (i.e. no cell padding as well), then this translates to

(53/48) x 10485760 ~ 11578027 bytes of cell data

2 x E1 = 2 x 2.048 Mbits/sec = 4.096 Mbits/sec = 4.096 x 10^6 bits/sec = 4096000 bits/sec = 512000 bytes/sec facility transmission speed

So, your facility can send 512000 bytes in 1 sec, and needs 11578027/512000 ~ 23 seconds to send the file.

Now if we take into account the overheads we ignored previously, this will increase. We also ignored for a while the latency you reported (RTT or one-way, it doesn't matter that much). If we also take into account TCP slow start, windowing and time it takes for TCP to adjust, it all adds up. Concurrent sessions can help, because the facility has capacity. It just takes the applications time to take advantage of it, so if you run concurrent sessions, the potential initial time lost (translated into unutilized capacity) as a total percentage of the transfer is reduced. Typically, in such cases you need to run tests that last quite longer than a minute to get realistic results (or use UDP tests to speed things up).

Kind Regards,

Maria

p.s. Forgot to say that the MSS value of applications can play a significant role. In iperf tests there is an option to change that to get better bandwidth efficiency.

View solution in original post

Giuseppe Larosa · ‎12-29-2009

Hello Rajiv,

when an ATM link is involved the time for SAR segmentation and reassembly appears in this kind of test.

I don't know what tool you are using but if possible try to perform multiple parallel transfers you should see that this is possible.

I remember I had used netperf in a test bed with ATM 155 Mbps in the middle, a single TCP test was giving only 46 Mbps instead of more then 90 in a LAN environment, however performing two tests in parallel was possible and lead to 90 Mbps of result.

Hope to help

Giuseppe

Rajiv Dasmohapatra · ‎12-29-2009

Hello Giuseppe,

Nice to hear from you again. By the way, I am using two E1 links between the two MGX. I am using FTP transfers and it is slow, although I have not tested with concurrent Data transfer sessions.

Is there any constraint, if i am using E1 links instead of E3 etc?

Giuseppe Larosa · ‎12-29-2009

Hello Rajiv,

SAR happens with any type of ATM link:

the process is that an IPv4 packet is placed inside an LLCSNAP header and then into an AAL5 PDU (enc aal5snap under pvc config is typical and default)

the resulting AAL5 PDU has to be sent as ATM cells.

on the other end the ATM cells have to be received collected to reassembly the sent AAL5 PDU, then the IPv4 packet is extracted and routed out a LAN interface.

This happens on the routers with an ATM interface.

so the fact that you are using ATM E1 doesn't change this.

Hope to help

Giuseppe

marikakis · ‎12-29-2009

Hi,

10 Mbytes = 10 x 2^20 bytes = 10485760 bytes of application data

If we ignore TCP/IP overheads and AAL5 and suppose those application data fully occupy cells (i.e. no cell padding as well), then this translates to

(53/48) x 10485760 ~ 11578027 bytes of cell data

2 x E1 = 2 x 2.048 Mbits/sec = 4.096 Mbits/sec = 4.096 x 10^6 bits/sec = 4096000 bits/sec = 512000 bytes/sec facility transmission speed

So, your facility can send 512000 bytes in 1 sec, and needs 11578027/512000 ~ 23 seconds to send the file.

Now if we take into account the overheads we ignored previously, this will increase. We also ignored for a while the latency you reported (RTT or one-way, it doesn't matter that much). If we also take into account TCP slow start, windowing and time it takes for TCP to adjust, it all adds up. Concurrent sessions can help, because the facility has capacity. It just takes the applications time to take advantage of it, so if you run concurrent sessions, the potential initial time lost (translated into unutilized capacity) as a total percentage of the transfer is reduced. Typically, in such cases you need to run tests that last quite longer than a minute to get realistic results (or use UDP tests to speed things up).

Kind Regards,

Maria

p.s. Forgot to say that the MSS value of applications can play a significant role. In iperf tests there is an option to change that to get better bandwidth efficiency.

Giuseppe Larosa · ‎12-29-2009

Hello Maria,

this is a true engineer's answer.

Best Regards

Giuseppe