rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

Hello,


> 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.

I'm curious. What network link is it? Is it a satellite link?


> 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 checked RFC3510. I didn't know that it recommends ROHC. The note
about TCP Timestamp option is not true any more. The TCP profile is
well-defined: http://tools.ietf.org/html/rfc6846

The ROHC library implements it. It is alpha quality in 1.7.x versions
but it will be fully ready for 2.0.0. In fact, it is already fully
ready in the master branch of the ROHC Git repository:
https://github.com/didier-barvaux/rohc


> I was, consequently, a bit surprised after the first tests, made
> after having established the IPROHC tunnel over my radio-link.

What IP/ROHC version do you use? What ROHC library version do you use?

As a side note, I highly recommend you to transmit the ROHC packets
directly in the X.25 frames if you're able to to do. It would save you
the IP bits.


> Please consider that – on the server side - I have :
> -	doubled the keepalive timeout, that now is set to 150. 

What is the link RTT?


> -	Set the packing rate to 3.
> -	Activated the bidirectional mode, while I need iperf, ftp
> and telnet connections.

The ROHC bidirectional mode is not related to bidirectional protocols
such as FTP or telnet. Bidirectional in the ROHC vocabulary means that
the ROHC decompressor may send some feedback to the remote ROHC
compressor. Bidirectional protocols can be handled with unidirectional
ROHC too. If your RTT is large, I even recommend you to use the
unidirectional mode.


> 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… 

Packing could introduce additional latency but not that large.

Could you please send me the logs (with debug traces enabled) when you
send a ping in the tunnel?

Could you please run the same test with packing set to 1?


> 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;

If the RTT is 24 seconds, did you increase the time that the ping
command waits for ping replies?


> 	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.

Yes, please. The logs could be helpful.


> 	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.

Was the iperf test a TCP or UDP test?

You say "tunnel crash". What do you mean? Does one of the tunnel
daemons stop abruptly? If yes, please provide me the last traces
in logs. And also the return code of the program when you run it in
foreground mode.


> 	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.

Those problems seems to be related to the control channel of the
IP/ROHC tunnel. The control channel uses TCP for reliability. However
on your slow link, TCP connection may require some tuning to work
reliably.


> 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

Hmm, it should not happen if the MTU of the interfaces, the ROHC
compression estimation and the IP/ROHC encapsulation overhead
estimation are correct.

What IP/ROHC version do you use?
What is the MTU of the basedev interface?
What is the MTU of the IP/ROHC interface?
Are they the same on both client and server side?


> I have finally seen that, switching the IPROHC from “unidirectional”
> to “bidirectional” in order to allow iperf, ftp and telnet over the
> link

See my note at the beginning of this email. Bidirectional ROHC does
not mean bidirectional protocols. Unidirectional ROHC mode is perfectly
fine with bidirectional protocols such as iperf, FTP or telnet.


> IPROHC seems starting transmitting on the “basedev” channel TCP
> in place of IP, in this case loosing the advantage of header size
> reduction.

The IP/ROHC program uses 2 different channels: one using TCP for the
control packets, one using IPv4 for the data packets. See
https://rohc-lib.org/wiki/doku.php?id=iprohc-overview#software_architecture


> 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.

ROHC seems a good fit for your problem. Hope my questions above will
help us to find the problem.

Regards,
Didier