[Since my original posting was inadvertently deleted by normally benevolent forces, I am replying again with a somewhat different reply]
factor wrote:Because it is expected that some percentage of packets will be lost between the cell tower and the laptop, mitigating the effect of a lost packet can assist throughput. TCP starts to back-off its transmission when it is losing packets ... the assumption being that their is network congestion somewhere along the path (not making allowance for the fact that the last mile may be a little lossy).
You assume that 3G networks don't have a link level error correcting protocol. I believe that UMTS networks can choose whether they wish to enable a link level retransmission protocol which effectively mitigates the effect of lost packets. I certainly hope that I'm not being charged for packets the UMTS network fails to deliver. I don't know whether Optus implements link level retransmission, nor do I know whether what is implemented is actually optimal for TCP/IP. Certainly, link and network level protocols that attempt to provide a reliable sub-network for higher level protocols can adversely impact TCP/IP performance. Venturi Wireless claims
that TCP is not suited for wireless networks and sells client and proxy products implementing the Venturi Transport Protocol
. Unwired uses this in their non-UMTS legacy network possibly along with Venturi's compression technology and some users report a benefit at least below a certain speed.
TCP can recover its speed faster if the latency between laptop and server is lower. If the TCP connection is actually between a Sydney based proxy server and Sydney based laptop, throughput will increase faster again following packet loss, this compared to the TCP connection being between a US based web server and the Sydney based laptop.
While latency has an effect, I think it is less significant in modem TCP implementations with SACK and fast recovery. You're also assuming that the overseas link contributes the most latency. The local mobile network can have significant and highly variable latency. If the wireless network implements link level retransmissions then the TCP round trip time will blow out making TCP slow to respond to packet loss. I'm inclined to think there would be a performance improvement provided the two TCP connections had a large enough buffer between them, but I don't know whether it would be significant. Performance of TCP/IP over mobile networks seems a complex area to me.
Screwing around with lossy compression of images at a proxy server, or generating mobile friendly web pages (have a good go at buggering up the content) is not ok though!!
Please have a look at Opera Turbo. Dazzled too, was initially skeptical. I agree that compression is not a one-size fits all solution and users should be able at the very least to decide whether they wish to participate. Opera for example allows you to reload individual images in higher quality, and only appears to lower quality on images that are referenced from a page and not standalone images. I would argue that users should also be able to decide if they wish to have their traffic proxied, since it is not totally transparent.
I would be perfectly happy for Exetel to charge me for the uncompressed data stream in this case, provide a performance benefit for us but keep the saving of throughput over the wireless component of the network.
Well, you might be happy, but I wouldn't be happy unless the performance benefit was significant enough to justify breaking the end-to-end ness of the TCP/IP connection (a bad thing since it introduces the possibility of packet loss and other unreliability). I do recognise that Exetel need to see a business benefit. I conjecture that by being more attractive to users with compressible data, user numbers and data consumption will increase. In any case, it seems a pity for Exetel to not compress data passed through Optus, allowing Optus to potentially benefit from network compression, while not receiving any discount for compressible data.