[ROHC v1.2.0 Tunnel Application] No observed feedback after lost

Asked by rmeas on 2010-02-10

I'm running some experiments with the provided ROHC tunnel application to observe the effect of packet loss on the overhead of the protocol. I'm using a UDP packet generator to send a stream over the tunnel. The tunnel is started with the following parameters on both machines:

rohctunnel rohc0 remote 192.168.0.11 local 192.168.0.10 port 5000 error uniform 1e-4 dir bidirectional

My understanding is that these parameters should start the compressor and associated decompressor with a small BER and feedback enabled. When streaming in one direction, it shows that packets are being dropped, but it does not reply with any feedback. Wouldn't the context become invalidated? An example of this behavior is shown below in the output of the decompressor on the receiving node. Furthermore, no feedback is sent on initialization of the tunnel. This makes me think that the mode is possibly stuck in unidirectional. It never seems to switch into optimistic or reliable. Is there a way to force the mode into optimistic or reliable?

Thanks for your help.

Cheers,
Ryan

[rohc_decomp.c:399 rohc_decompress()] decompress the packet #19255
[rohc_decomp.c:550 d_decode_feedback_first()] skip 0 byte(s) of padding
[rohc_decomp.c:560 d_decode_feedback_first()] add-CID present: 0xe3 -> CID = 3
[rohc_decomp.c:618 d_decode_header()] add-CID present: CID = 3 (0x3)
[d_generic.c:2446 d_generic_decode()] decode the packet (type 0)
[d_generic.c:2527 decode_uo0()] first byte = 0x57 (real CRC = 0x7, SN = 0xa)
[d_generic.c:3354 do_decode_uo0_and_uo1()] SN = 14154
[d_udp.c:489 udp_decode_uo_tail_udp()] UDP checksum = 0x1d95
[d_generic.c:5374 build_uncompressed_ip6()] Payload Length = 0x3000
[d_udp.c:544 udp_build_uncompressed_udp()] UDP checksum = 0x1d95
[d_udp.c:548 udp_build_uncompressed_udp()] UDP length = 0x0030
[d_generic.c:3490 do_decode_uo0_and_uo1()] size = 48 => CRC = 0x7
[d_generic.c:5683 update_inter_packet()] current time = 3870667462 and last time = 3870667370
[d_generic.c:5697 update_inter_packet()] inter_arrival_time = 569 and current arrival delta is = 92
[d_generic.c:2625 decode_uo0()] ROHC payload (length = 40 bytes) starts at offset 3
[d_generic.c:2458 d_generic_decode()] uncompressed packet length = 88 bytes
[rohc_decomp.c:411 rohc_decompress()] state in decompressor = 3
[rohc_decomp.c:484 rohc_decompress()] feedback curr -12
[rohc_decomp.c:491 rohc_decompress()] feedback curr 0
ROHC packet(s) probably lost between seq = 25132 and seq = 25135
[rohc_decomp.c:399 rohc_decompress()] decompress the packet #19256
[rohc_decomp.c:550 d_decode_feedback_first()] skip 0 byte(s) of padding
[rohc_decomp.c:560 d_decode_feedback_first()] add-CID present: 0xe3 -> CID = 3
[rohc_decomp.c:618 d_decode_header()] add-CID present: CID = 3 (0x3)
[d_generic.c:2446 d_generic_decode()] decode the packet (type 0)
[d_generic.c:2527 decode_uo0()] first byte = 0x6e (real CRC = 0x6, SN = 0xd)
[d_generic.c:3354 do_decode_uo0_and_uo1()] SN = 14157
[d_udp.c:489 udp_decode_uo_tail_udp()] UDP checksum = 0xa864
[d_generic.c:5374 build_uncompressed_ip6()] Payload Length = 0x3000
[d_udp.c:544 udp_build_uncompressed_udp()] UDP checksum = 0xa864
[d_udp.c:548 udp_build_uncompressed_udp()] UDP length = 0x0030
[d_generic.c:3490 do_decode_uo0_and_uo1()] size = 48 => CRC = 0x6
[d_generic.c:5683 update_inter_packet()] current time = 3870667555 and last time = 3870667462
[d_generic.c:5697 update_inter_packet()] inter_arrival_time = 330 and current arrival delta is = 93
[d_generic.c:2625 decode_uo0()] ROHC payload (length = 40 bytes) starts at offset 3
[d_generic.c:2458 d_generic_decode()] uncompressed packet length = 88 bytes
[rohc_decomp.c:411 rohc_decompress()] state in decompressor = 3
[rohc_decomp.c:484 rohc_decompress()] feedback curr -12
[rohc_decomp.c:491 rohc_decompress()] feedback curr 0

Question information

Language:
English Edit question
Status:
Answered
For:
rohc Edit question
Assignee:
No assignee Edit question
Last query:
2010-02-10
Last reply:
2010-05-04

> My understanding is that these parameters should start
> the compressor and associated decompressor with a
> small BER and feedback enabled.

Yes, you're right.

> When streaming in one direction, it shows that packets are
> being dropped, but it does not reply with any feedback.
> Wouldn't the context become invalidated?

Not necessarily. The context becomes invalid only if the ROHC
decompressor detects a problem such as a CRC failure. In such
cases, the decompressor _may_ send a negative feedback if the
(decompression failures / decompression successes) ratio
increases too much.

> An example of this behavior is shown below in the output of
> the decompressor on the receiving node.

In your example, there is no decompression failure, so no problem
is detected, so no feedback is transmitted. It probably appends because
your UDP stream is very regular (all successive packets are very similar),
so the lost packets do not cause a desynchonization between the
compressor context and the decompressor context.

> Furthermore, no feedback is sent on initialization of the tunnel. This
> makes me think that the mode is possibly stuck in unidirectional. It
> never seems to switch into optimistic or reliable. Is there a way to
> force the mode into optimistic or reliable?

It should transit to O-mode upon first successful decompression of packet.
Search for string "change from mode 1 to mode 2" in compression traces
and search for string "send an ACK feedback" in decompression traces.
Do you find them ? If not, contact me again with the compression and
decompression traces of the first 10 packets.

Didier Barvaux
Viveris Technologies
http://www.tech.viveris.com/opensource/

Ramya J (ramyaa-29) said : #2

Hello,
          I downloaded the ROHC-1.2.0 package from launchpat.net. I installed the packages(automake,m4,autoconf,bison,flex,perl,libtool,help2man,texinfo,gcc,libpcap,gawk) and compiled the package as follows:
step 1: ./autogen.sh --prefix=/usr/local/bin
step 2: make all
step 3: make install

Next created the virtual interface using

ifconfig eth0:rohc0 192.168.1.8 netmask 255.255.255.0 up

Next I executed rohctunnel in /usr/local/bin/bin as :

./rohctunnel eth0:rohc0 remote 192.168.1.7 local 192.168.1.8 port 5000

eth0:rohc0 created, fd 3
UDP socket created on port 5000, fd 4
[rohc_comp.c:67 rohc_alloc_compressor()] creating compressor
[rohc_comp.c:1302 c_piggyback_get()] add 0 byte(s) of feedback data
[rohc_comp.c:1302 c_piggyback_get()] add 0 byte(s) of feedback data
[rohc_comp.c:1302 c_piggyback_get()] add 0 byte(s) of feedback data
[rohc_comp.c:1302 c_piggyback_get()] add 0 byte(s) of feedback data

Is this right?

Next, I executed the command

ip link set eth0:rohc0
 ip -4 addr add 10.0.0.1/24 dev eth0:rohc0

Did this on both the systems and tried to ping from one system to another as:

ping 10.0.0.2

Next tried to capture those packets in another system using
tcpdump -v -x -i eth0:rohc0

The output is as follows:
tcpdump: listening on eth0:rohc0, link-type EN10MB (Ethernet), capture size 96 bytes
11:34:35.836636 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 108) 192.168.1.3 > 192.168.1.8: ICMP echo request, id 41486, seq 37, length 88
    0x0000: 4500 006c 0000 4000 4001 b735 c0a8 0103
    0x0010: c0a8 0108 0800 6b62 a20e 0025 a16b df4b
    0x0020: 4a7c 0d00 0809 0a0b 0c0d 0e0f 1011 1213
    0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
    0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
    0x0050: 3435
11:34:35.905861 IP (tos 0x0, ttl 64, id 2844, offset 0, flags [none], proto ICMP (1), length 108) 192.168.1.8 > 192.168.1.3: ICMP echo reply, id 41486, seq 37, length 88
    0x0000: 4500 006c 0b1c 0000 4001 ec19 c0a8 0108
    0x0010: c0a8 0103 0000 7362 a20e 0025 a16b df4b
    0x0020: 4a7c 0d00 0809 0a0b 0c0d 0e0f 1011 1213
    0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
    0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
    0x0050: 3435

From the logs it can be seen that there is no compression happening.
Please point me in the right direction.

Regards,
Ramya

Hi Ramya,

> I downloaded the ROHC-1.2.0 package from launchpat.net. I installed the
> packages(automake,m4,autoconf,bison,flex,perl,libtool,help2man,texinfo,gcc,
> libpcap,gawk) and compiled the package as follows:
> step 1: ./autogen.sh --prefix=/usr/local/bin
> step 2: make all
> step 3: make install
>
> [...]
>
> Is this right?

Yes, the commands are OK.

> Next, I executed the command
>
> ip link set eth0:rohc0
> ip -4 addr add 10.0.0.1/24 dev eth0:rohc0

That is correct too.

> Next tried to capture those packets in another system using
> tcpdump -v -x -i eth0:rohc0
>
>The output is as follows:
> tcpdump: listening on eth0:rohc0, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:34:35.836636 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 108) 192.168.1.3 > 192.168.1.8: ICMP echo request, id > 41486, seq 37, length 88
> 0x0000: 4500 006c 0000 4000 4001 b735 c0a8 0103
> 0x0010: c0a8 0108 0800 6b62 a20e 0025 a16b df4b
> 0x0020: 4a7c 0d00 0809 0a0b 0c0d 0e0f 1011 1213
> 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
> 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
> 0x0050: 3435
> [...]
> From the logs it can be seen that there is no compression happening.
> Please point me in the right direction.

ROHC compression is happening but you can not see it with a tcpdump command on the interface "eth0:rohc0". On this interface, you can only capture the uncompressed packets before they went to the ROHC compressor and the decompressed packets generated by the ROHC decompressor. The ROHC packets can be captured on the underlying network interface (it seems to be the "eth0" interface for you). The ROHC packets are transmitted in UDP datagrams with port 5000. The UDP payload is a sequence number followed by the compressed ROHC data.

Regards,

Didier Barvaux
Viveris Technologies
http://www.tech.viveris.com/opensource/

Can you help with this problem?

Provide an answer of your own, or ask rmeas for more information if necessary.

To post a message you must log in.