latency & NAT issues -- question

[linuxguy]

I still haven't had a chance to try out GPRS/EDGE yet to see for myself -- but I
was talking to somebody at a conference last week who has a vodacom 3G
card and says it's disappointing in terms of end-to-end latency.

Doing some reading -- it seems like there was a bunch of research during
1999-2002 with TCP performance of GPRS, and the short summary was:

- GPRS data is sent in a series of TBFs (temporary block flows?). A TBF
corresponds to a temporary allocation of timeslots while there is data
actively being sent.
- the data transfer rates are pretty good once the TBF is established, but
it takes a while to establish the TBF, like 1sec+. (why does it take long
to establish the TBF?)
- this means interactive character-based apps (my friend was using ssh)
are pretty awful
- it also has a bad interaction with TCP due to the three way handshake
and slow-start/congestion avoidance behaviour so that TCP connections
take quite awhile to get started as their initial RTT estimates are very
high while the TBF is being established.

What is performance *actually* like? The bitrates for EDGE and even GPRS
look fine -- at least as good as what I get on dialup. But dialup I get a
180ms RTT to the other end of the link from the first packet.

The work that the guys were doing in the articles was to use an HTTP
proxy that carried all the data over a custom link-layer protocol running
over UDP.

Which brings me to NAT issues on the APN -- I understand from other
messages that the MyMTN APN gives you non-routable IPs (172. somethings)
ICMP doesn't work -- but will UDP work? Does anybody know what the
NAT timeouts are for TCP and UDP?

I s'pose I should just get a phone and try it out -- but I keep dithering
between the current good deals on the 6230 and the slightly more
cooler 6630...although I won't be living near 3G any time in the near
future. But the Symbian 60 stuff sounds like it has a lot more
development possibilities. (See -- I don't want a phone so much as
a computer...I hate phones...I was really happy in my office when they
gave me a phone that didn't ring. I wrote a script that watched the
mgetty logfiles on my machine and would pop up an Xmessage to tell
me when the phone was ringing. That's the way it should be).

Thanks,

 

[ScrnScrm]

Which brings me to NAT issues on the APN -- I understand from other
messages that the MyMTN APN gives you non-routable IPs (172. somethings)
ICMP doesn't work -- but will UDP work? Does anybody know what the
NAT timeouts are for TCP and UDP?

ICMP is firewalled - its to stop people pinging you and chowing up your bandwidth. In essense, its easier for them to do this because leaving the responsibility of proper firewalling to the average end user would be courting disaster... Btw - Vodacom also do this...

You can get a legal IP if you want, but you have to ask for it.

Wrt latency, it depends entirely how busy the BTS is. Personally, I have had no problems with SSH or RDP connections through a VPN connection back to the office, except when I am on CS2 on GPRS.
There are some easy workarounds to any DNS issues, especially if you are running Linux...
Ciao -

 

[MTNBroadband]

I still haven't had a chance to try out GPRS/EDGE yet to see for myself -- but I
was talking to somebody at a conference last week who has a vodacom 3G
card and says it's disappointing in terms of end-to-end latency.

Doing some reading -- it seems like there was a bunch of research during
1999-2002 with TCP performance of GPRS, and the short summary was:

- GPRS data is sent in a series of TBFs (temporary block flows?). A TBF
corresponds to a temporary allocation of timeslots while there is data
actively being sent.
- the data transfer rates are pretty good once the TBF is established, but
it takes a while to establish the TBF, like 1sec+. (why does it take long
to establish the TBF?)
- this means interactive character-based apps (my friend was using ssh)
are pretty awful
- it also has a bad interaction with TCP due to the three way handshake
and slow-start/congestion avoidance behaviour so that TCP connections
take quite awhile to get started as their initial RTT estimates are very
high while the TBF is being established.

What is performance *actually* like? The bitrates for EDGE and even GPRS
look fine -- at least as good as what I get on dialup. But dialup I get a
180ms RTT to the other end of the link from the first packet.

The work that the guys were doing in the articles was to use an HTTP
proxy that carried all the data over a custom link-layer protocol running
over UDP.

Which brings me to NAT issues on the APN -- I understand from other
messages that the MyMTN APN gives you non-routable IPs (172. somethings)
ICMP doesn't work -- but will UDP work? Does anybody know what the
NAT timeouts are for TCP and UDP?

Thanks,

The delays are primarily to do with allocation of network resources. In order to offer an 'always connected' service on the airwaves when you might not use the service for days on end, there needs to be a system of prioritisation. In broad terms, when you are actively sending and receiving you are pre-allocated future resources and the RTT improves. When you stop sending you have to ask for resources to re-send and there is the brief delay when the handset and network re-negotiated. After a long delay you are dropped down one more level so that you are still 'connected' but idle.

I will need to check the latest average RTT figures because they improve every year. Last year around 70ms was shaved off our network. They are in the order of 100s of milliseconds.

The NAT timeouts I should send you by private mail as they relate to security.

Let me know by PM where you live so I can get our handset person to advise on the handset.