rohc team mailing list archive

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

Hello,

a short additional information. 
The "switch" to  TCP over the baseline interface, that I reported below after 
activation of "bidirectional mode", seems affecting only the iperf tests.
Using FTP the baseline channel still uses IPv4 packets.
First FTP tests over the simulated testbed (no radio link) give the following 
results :

"Basedev" interface : 1774 bytes received in 9.02 secs 
"IPROHC" tunnel over the same interface : 1774 bytes received in 12.05 secs 

Regards
UP



>----Messaggio originale----
>Da: ugop@xxxxxxxxx
>Data: 6-giu-2015 7.45
>A: <rohc@xxxxxxxxxxxxxxxxxxx>
>Ogg: [Rohc] Unexpected poor performances using IPROHC tunnel over a very thin 
radio link
>
>
>
>
>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
>
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~rohc
>Post to     : rohc@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~rohc
>More help   : https://help.launchpad.net/ListHelp
>