[e2e] Reacting to corruption based loss

[Ian McDonald]

Hi there,

Detlef Bosau wrote:
> So let us take 5 % for the moment. This appears to me a reasonable radio
> block corruption rate which can be found in many papers, so hopefully it
> is sometimes met even in reality. (Perhas, some person experienced with
> mobile networks can provide details here.)
> 

Will attempt to from my experience!
...
> That is why I did not give pure e2e approaches in the "mobile access net
> scenario" further consideration, because with packet corruption rates
> 0.7 or 0.8 congestion control does not matter. It´s simply not the
> problem. The problem are the inacceptable rate of packet retransmissions
> which is not only annoying for the user, because it takes large numbers
> of transmissions and large amounts of time to have a packet eventually
> delivered. It is annoying for the rest of the world as well, because
> even wirebound network links with small corruption rates would be
> occupied by retransmissions.
> 
> 
> Please correct me if I´m wrong there. But I´m totally convinced that in
> really lossy networks, e.g. mobile wireless links, congestion control
> and loss differentiation simply _miss_ the problem. 
> 
I couldn't agree more with this last part.

My experience has been as a software development manager at ECONZ
(http://www.econz.co.nz) where we worked with mobile networks across
radio, cellular, GPRS etc. The project that I was personally responsible
was working on AMPS cellular and CDPD with, at times, very low signals.

Our experience was that for AMPS we knocked the baud rate down as low as
possible to 4.8K and abandonded the use of TCP/IP altogether as we could
hit packet rate losses of 40% quite regularly and dropped connections.

We implemented a protocol on top of UDP where we just used a sliding
window (from memory about 16) and knocked the packet size to a small
size (about 100 bytes max) and allowed out of order packets but with a
timeout retransmission.

The throughput on this compared to TCP (Reno) was around 1000% higher
(yes 10 x).

With better conditions we still got much better throughput.

This was one of the reasons why ECONZ did so well as a company as we
could actually transmit data to remote locations in a reasonable timeframe.

Anyway, I may be living in the past a little but that was my experience!

Regards,

Ian
WAND Network Research
http://www.wand.net.nz