SatSig topic:

iDirect Inbound/Upload TCP/reliable problem

(Read 10970 times)

Sep 20^th, 2011 at 1:44pm

Hi All,

i'm having problem with remote upload / inbound TCP traffic.
our HUB manage about 20 remotes in 2 different line card/network.
remote end using modem iDirect 3000 series and 5000 series.

if we upload tcp/reliable (email) traffic it will be very slow..
doesn't matter the upload QOS limit 256 / 512 / 1024 kbps, the sat traffic (blue line / reliable) will only reach about 0-200 kbps maximum.

both line card/network are the same problem. i also have tested on some remote end, and the result still the same.

otherwise, unreliable traffic (UDP) upload will flow smoothly and could reach full flat maximum QOS limit.

i tried using Mikrotik bandwidth test point to point.
the same result like above UDP will reach full flat maximum, while TCP only reach 0-200 kbps no matter how big the QOS limit.

are there anyone having same problem in iDirect system?
and anyone have solution for this case ?

Sep 23^rd, 2011 at 11:01am

0-200kbps is more than likely the bandwidth delay product for your carrier. Are you relying on iDirects native acceleration for tcp enhancement or are you using another vendors product?

Bottomline - Your problem is clearly windowing due to the lengthy round trip times (latency). You need to buy into a good PEP for tcp enhancement. There are a lot of flavors out there...some strictly software, some hardware and software...examples: Accelenet, Riverbed, Blue Coat, etc. Take a look at each of them and determine if they meet your requirements for moving packets.

Sep 25^th, 2011 at 4:06pm

Hi Mike,

thanks for your advise.
yes, im only relying on iDirect system, no other product.

is there any other way like modify something on HUB configuration, instead using another software/hardware ? or maybe from remote modem ?

anyway thanks again for your info.

Sep 26^th, 2011 at 10:13am

The TDMA return link to the teleport involves discrete burst transmissions from the remote sites.

If the customers are generally sending very small amounts of data (e.g. mouse click url requests) then it makes sense to use a small TDMA burst length. If the customers are generally sending very large data/image/video files then a long TDMA burst length would be more efficient.

This discussion may be relevant:
https://www.satsig.net/topics/satsig-topic-num=1302424761.htm

Best regards, Eric.

Sep 26^th, 2011 at 3:03pm

Hi Eric,

thanks for your reply..
actually i also suspect the problem on latency which caused TCP slow, and more clear after Mike replied.

i had tried some test on one of test remote, by changing QOS setting on HUB but nothing can improve.
i also tried change remote modem setting, most on "spoof params" , but still no luck.

there was a pattern from traffic graph when i did some test. the same like you said small data TCP will flow normally, as the first burst could kicked the traffic to reach maximum QOS limit. but only for first 1-3 second, after that will start fluctuation with pattern 0 and 30-150 kbps.

from the topic that you gave, look like its mostly related to the time slot.
i'm still doing some test. will post here if any improvement.
please comment if any other suggestion.

thanks a lot..

Sep 28^th, 2011 at 11:43am

Andrew, if you own and manage the hub, I would consider using tcpdump (or even wireshark) to sniff the upstream side (eth0) of the PPs for possible fragmentation. tcpdump is the fastest method as it is built into the PPs. The fact that you are able to acheive up to 200kbps of thoughput indicates to me that you are likely NOT fragmenting, but you need to check, just to be sure.

I think your problem is clearly the lack of tcp enhancement (acceleration) due to the latent satellite enviro. To be honest, I have never used the iDirect native acceleration, but I am pretty sure it is non-configurable. It is simply there...looking at headers to see if any packets meet the criteria for spoofing. I would recommend that you look for an alternative to iDirects native enhancement. Preferably a software or hardware solution that has some content caching ability. Acceleration+ability to content cache is a double bonus. With the proper enhancement, not only are you moving your tcp traffic quickly (in a satellite enviro), you get the added benefits of not passing the data across the link numerous times. There are vendors out there that off these capabilities. You customer base will see a night and day difference in their remote end experience.

Oct 5^th, 2011 at 5:04am

hi Mike,

thanks so much for your suggestion.

i'm not the owner nor the manager for the HUB, just one of technical staff.

i will have a look on the alternate software and hardware for this solution.

Oct 12^th, 2011 at 1:34pm

Suggestion **

1) Change the MTU Size on iDirect hub with a Custom Key and Pass through the TCP Traffic.

2) Making a new Application Profile using Group Qos prioritize the TCP Port of or Ip Address and than check the traffic.

Oct 12^th, 2011 at 2:32pm

Hi,

I have to design a 2Mbps SCPC link for 5 sites along with 1 central site.can any one suggest me the size of antenna used at remote as well as at central site.the frequency band is ku.

please suggest

Oct 12^th, 2011 at 10:15pm

What are the uplink and downlink bit rates at each site ?

e.g. 2 Mbit/s from hub, broadcast to all sites. Each site transmits 128 kbit/s SCPC. Remote sites receive 1 carrier and transmit 1 carrier. Hub has 5 active receivers. Hub transmits 1 carrier. Assumes hub and remotes are in same beam connected back on itself so all sites can see all carriers. You need to rent transponder bandwidth sufficient for all 6 carriers.

Where are the remote sites lat/long ? Where is the hub ? You need to know on what beam contours they lie in the uplink and downlink beam maps.

What satellite and beam ? You need to get the transponder operating point (input/output back off and pfd to saturate and gain setting) from the satellite operator.

To minimise your monthly costs use somewhat larger antennas and a higher order modulation method, e.g 8-PSK or 16-QAM. As a starting point for link budget analysis a 2.4m or 3.8m dish is suggested for the hub with 1.8m dishes at the remote sites. BUCs 2 to 10W. Don't commit to purchase till the link budget is approved by the satellite operator and you are happy with the link margins (rain fade, uplink power control range)

Suggest one CDM-570L modem at every site plus a CDM564L at the hub.

Best regards, Eric.

Oct 13^th, 2011 at 6:58am

Hi Eric,
the remote link consists of
1. Raw internet 128kbps
2. Data,voice & fax 1024kbps

the hub is in muscat Oman and the remote sites are located around 500 kms from hub.

the satellite is Singtel ST-2

Regards
firdous

Oct 13^th, 2011 at 9:12am

What are the uplink and downlink bit rates at each site ?

"the remote link consists of
1. Raw internet 128kbps
2. Data, voice & fax 1024kbps"

This is ambigious. It does not say what the remote site is transmitting and what the remote site is receiving.

You need to write a complete list of all the carriers that will operate, where they come from and where they go to. Some carriers, such as the hub outlink, may be multi-destination.

Coverage map for Singtel ST-2

All your sites to be in one beam. Check you exact proposed locations - I've just drawn an approx area with the red circle.
You need a transponder cross-connected back on itself so that your uplink signals come back down into the same beam. (If your hub had been in Hong Kong and remote sites in ME, you would have needed capacity in a pair of transponders cross-connected beam 1 up and beam 3 down plus beam 3 up and beam 1 down).

You now need the beam contour maps for downlink eirp and uplink G/T and PDFsat, for Ku band beam 3. Also the multi-carrier transponder operating point and transponder gain setting.

Can you contact Singtel and ask them if there is any available capacity to lease in Ku band beam 3, plus price quote per MHz, plus all technical details and what limits etc your network and transmit antennas must comply with, such as transmit cross-pol interference, transmit off-axis sidelobes etc.?

Best regards, Eric.