rohc team mailing list archive

["ugop@xxxxxxxxx" <ugop@xxxxxxxxx>]

Hello everyone, Didier,
I have started some very preliminary tests using the IPROHC over a slow long-
distance radio link, trying to improve the performances on this TCP-IP channel.
The channel is really slow : 300 bps is the theoretical bandwidth of the link, 
an iperf unidirectional test gives an average 140 bps bandwidth overall. For 
this reason my expectation was to get significant improve using ROHC in an 
RFC3150 compliant scenario.
The link-layer protocol it’s a bit exotic : AX25 (dialect of the X.25), used 
on radio amateur tests, telemetry and low cost satellites links.
The test is made over Linux Debian “Wheezy”, fresh installations. AX25 is part 
of Linux kernel.
I was, consequently, a bit surprised after the first tests, made after having 
established the IPROHC tunnel over my radio-link.
Please consider that – on the server side - I have :
-	doubled the keepalive timeout, that now is set to 150. 
-	Set the packing rate to 3. 
-	Activated the bidirectional mode, while I need iperf, ftp and telnet 
connections.
Consider that the “basedev” interface MTU is 254, due to the special features 
of the channel.
The roundtrip time using ICMP (84 bytes) over a one-hop link is :
•	7,4 sec without tunnel
… and using the IPROHC on the same channel it becomes :
•	24  sec with the tunnel (!)
Ok, there is no TCP behind… 
The link it’s not stable at all : 
	More than 30% of ping requests are lost on the tunnel, while on the native 
AX25 radio link (almost) none is lost;
	Some unexpected tunnel termination occurs during basic text. They seem to be 
timeouts, but several not easy to understand messages are set in the syslog. I 
can publish the logs, if required.
	I was able to finalize a (short) iperf test only one time : in other cases 
iperf stops, often due to tunnel crash but sometime to some not easy-to-
understand pauses (transmission stops, also if the tunnel is still alive : if I 
stop the test and I ping, the other side of the tunnel answers). May be an 
iperf timeout also.
	I made a parallel sniffing of the same ICMP dialogue (being unable to sniff 
the iperf exchange) both capturing the “basedev” interface and the tunnel 
interface : looking at low level, at a first glance there are several DUP 
packages and the dialogue stops with several RST “red” packages.

Considered the problems, I replicated the  tests described above over a 
“virtualized” channel (that means : AX25 piped over Ethernet or serial links in 
place of radio links), fixed delay of 4000 ms added using netem to the 
“basedev” interface in order to simulate (roughly : no losses, no delay 
variations) the real channel behavior. 
Also in this more controlled condition the test gives results not really 
different : RTT of the tunnel almost 10 – 30 times greater of the basic RTT, 
iperf test sometime succeeding but very instable, with frequent crashes on 
IPROHC server side. Normally I’m able to perform the first iperf (also iperf –
d) test after having activated the IPROHC tunnel. The second  always crashes 
and the last messages that I can read in the syslog of the IPROHC server 
machine shows the following error (normally repeated several times) :

iprohc_server[3927]: discard too large compressed packet: packet is xxx-byte 
long, but packing frame can only handle up to 233-byte packets

The “basedev” channel is still alive, and after the crash of the tunnel I can 
restart server and client and again being able to “ping” without touching the 
lower level (AX25) interface.
In these virtualized conditions (in any case the real radio link is surely 
slower and the virtual testbed should be tuned better in order to simulate 
realistically the field conditions) iperf –d gives the following results :
a)	“basedev” link : about 2,53 Mbps
b)	IPROHC link : 57 Kbps (with strong variance)
Logs and pcap captures available if required. 
I have finally seen that, switching the IPROHC from “unidirectional” to 
“bidirectional” in order to allow iperf, ftp and telnet over the link, IPROHC 
seems starting transmitting on the “basedev” channel TCP in place of IP, in 
this case loosing the advantage of header size reduction. Not sure that this 
fact is able to explain all the overall bandwidth reduction… Of course this 
behavior prevents my RFC3150 wishes   
I’m consequently a bit confused.
Any suggestion or remark helping to analyze better the problem will be 
strongly appreciated, and also considerations regarding the unexpected 
reduction of overall bandwidth.

Best regards
Ugo Poddine