ROHC tunnel: meaning of fields in (de)compression statistics

Asked by Khaan on 2009-10-12

Hello all,

Thank you so much for sharing the resource and helping from time to time. I was to setup rohc tunnel and induce errors. Currently Im saving compression and decompression profiles in file as mentioned in recent post.

3> rohc_comp.stats
4> rohc_decomp.stats

can someone explain the names\context of the field values stored in files. I was able to do most of the rohc_comp.stats but was unable to do so for rohc_decomp.stats.

as I see the rohc_comp.stats fields are

sequence_no, rohc_mode, rohc_state, IP_header_size, UDP_header_size, x, y , z

Im not sure of the last three fields, Im sure these the compression stats but what exactly. what about the rohc_decomp.stats fields?

with kind regards,

Shaan

Question information

Language:
English Edit question
Status:
Answered
For:
rohc Edit question
Assignee:
No assignee Edit question
Last query:
2011-07-25
Last reply:
2011-08-01

This question was reopened

The compression statistics contain one line per packet that is transmitted through the ROHC tunnel. The fields on every line are in order:
 - the sequence number of the packet (this sequence may eventually overflow and the result is undetermined),
 - the mode of the ROHC compressor (among "error", "U-mode", "O-mode" and "R-mode"),
 - the state of the ROHC compressor (among "error", "IR", "FO" and "SO"),
 - the total length of all uncompressed IP packets (header + payload),
 - the total length of all uncompressed IP headers (header only, no payload),
 - the total length of all compressed ROHC packets (header + payload),
 - the total length of all compressed ROHC headers (header only, no payload),
 - the number of packets dropped by the tunnel.
These fields are printed at the very end of the "tun2udp" function in the source code of the tunnel application.

The decompression statistics contain one line per packet that is received through the ROHC tunnel. The fields on every line are in order:
 - the sequence number of the packet (this sequence may eventually overflow and the result is undetermined),
 - the total number of packets that were not correctly received (packets lost on the network and packets that the ROHC library failed to decompress correctly),
 - the total number of packets that were lost on the network,
 - the total number of packets that the ROHC library failed to decompress correctly.
These fields are printed by the "print_decomp_stats" function in the source code of the tunnel application.

Khaan (pizwan80) said : #2

Thank you for the help. I have attached one of the files which i dumped at
the decompresser, there seems to be a problem with 2nd and 3rd column. Is
this the overflow?

with kind regards,

Shaan

On Mon, Oct 12, 2009 at 4:06 PM, Didier Barvaux <
<email address hidden>> wrote:

> Question #85577 on rohc changed:
> https://answers.launchpad.net/rohc/+question/85577
>
> Status: Open => Answered
>
> Didier Barvaux proposed the following answer:
> The compression statistics contain one line per packet that is transmitted
> through the ROHC tunnel. The fields on every line are in order:
> - the sequence number of the packet (this sequence may eventually overflow
> and the result is undetermined),
> - the mode of the ROHC compressor (among "error", "U-mode", "O-mode" and
> "R-mode"),
> - the state of the ROHC compressor (among "error", "IR", "FO" and "SO"),
> - the total length of all uncompressed IP packets (header + payload),
> - the total length of all uncompressed IP headers (header only, no
> payload),
> - the total length of all compressed ROHC packets (header + payload),
> - the total length of all compressed ROHC headers (header only, no
> payload),
> - the number of packets dropped by the tunnel.
> These fields are printed at the very end of the "tun2udp" function in the
> source code of the tunnel application.
>
> The decompression statistics contain one line per packet that is received
> through the ROHC tunnel. The fields on every line are in order:
> - the sequence number of the packet (this sequence may eventually overflow
> and the result is undetermined),
> - the total number of packets that were not correctly received (packets
> lost on the network and packets that the ROHC library failed to decompress
> correctly),
> - the total number of packets that were lost on the network,
> - the total number of packets that the ROHC library failed to decompress
> correctly.
> These fields are printed by the "print_decomp_stats" function in the source
> code of the tunnel application.
>
> --
> You received this question notification because you are a member of ROHC
> Team, which is an answer contact for rohc.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~rohc <https://launchpad.net/%7Erohc>
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~rohc <https://launchpad.net/%7Erohc>
> More help : https://help.launchpad.net/ListHelp
>

Khaan (pizwan80) said : #3

Sorry I guess attachment didnt work, let me paste the decompresser profile
for first 100 packets. I have simulated it for 10,000 packets, Compressor is
working Perfectly.

Thanks again for the help.

with kind regards,

Shaan

1 0 0 0
2 0 0 0
3 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
7 0 0 0
8 0 0 0
9 0 0 0
10 0 0 0
11 0 0 0
12 0 0 0
13 0 0 0
14 0 0 0
15 0 0 0
16 0 0 0
65535 65519 65518 1
18 65518 65517 1
19 65517 65516 1
20 65516 65515 1
21 65515 65514 1
65535 65516 65514 2
23 65515 65513 2
24 65514 65512 2
25 65513 65511 2
26 65512 65510 2
27 65511 65509 2
28 65510 65508 2
29 65509 65507 2
30 65508 65506 2
31 65507 65505 2
32 65506 65504 2
33 65505 65503 2
34 65504 65502 2
35 65503 65501 2
36 65502 65500 2
37 65501 65499 2
38 65500 65498 2
39 65499 65497 2
40 65498 65496 2
41 65497 65495 2
42 65496 65494 2
43 65495 65493 2
44 65494 65492 2
45 65493 65491 2
46 65492 65490 2
47 65491 65489 2
48 65490 65488 2
49 65489 65487 2
50 65488 65486 2
51 65487 65485 2
52 65486 65484 2
53 65485 65483 2
54 65484 65482 2
55 65483 65481 2
56 65482 65480 2
57 65481 65479 2
58 65480 65478 2
59 65479 65477 2
60 65478 65476 2
61 65477 65475 2
62 65476 65474 2
63 65475 65473 2
64 65474 65472 2
65 65473 65471 2
66 65472 65470 2
67 65471 65469 2
65535 65472 65469 3
69 65471 65468 3
70 65470 65467 3
71 65469 65466 3
72 65468 65465 3
73 65467 65464 3
74 65466 65463 3
75 65465 65462 3
76 65464 65461 3
77 65463 65460 3
78 65462 65459 3
79 65461 65458 3
80 65460 65457 3
81 65459 65456 3
82 65458 65455 3
83 65457 65454 3
84 65456 65453 3
85 65455 65452 3
86 65454 65451 3
87 65453 65450 3
88 65452 65449 3
89 65451 65448 3
90 65450 65447 3
91 65449 65446 3
92 65448 65445 3
93 65447 65444 3
94 65446 65443 3
95 65445 65442 3
96 65444 65441 3
97 65443 65440 3
98 65442 65439 3
99 65441 65438 3
100 65440 65437 3

On Mon, Oct 12, 2009 at 4:21 PM, Shaan
<email address hidden>wrote:

> Your question #85577 on rohc changed:
> https://answers.launchpad.net/rohc/+question/85577
>
> Status: Answered => Open
>
> You are still having a problem:
> Thank you for the help. I have attached one of the files which i dumped at
> the decompresser, there seems to be a problem with 2nd and 3rd column. Is
> this the overflow?
>
> with kind regards,
>
> Shaan
>
> On Mon, Oct 12, 2009 at 4:06 PM, Didier Barvaux <
> <email address hidden>> wrote:
>
> > Question #85577 on rohc changed:
> > https://answers.launchpad.net/rohc/+question/85577
> >
> > Status: Open => Answered
> >
> > Didier Barvaux proposed the following answer:
> > The compression statistics contain one line per packet that is
> transmitted
> > through the ROHC tunnel. The fields on every line are in order:
> > - the sequence number of the packet (this sequence may eventually
> overflow
> > and the result is undetermined),
> > - the mode of the ROHC compressor (among "error", "U-mode", "O-mode" and
> > "R-mode"),
> > - the state of the ROHC compressor (among "error", "IR", "FO" and "SO"),
> > - the total length of all uncompressed IP packets (header + payload),
> > - the total length of all uncompressed IP headers (header only, no
> > payload),
> > - the total length of all compressed ROHC packets (header + payload),
> > - the total length of all compressed ROHC headers (header only, no
> > payload),
> > - the number of packets dropped by the tunnel.
> > These fields are printed at the very end of the "tun2udp" function in the
> > source code of the tunnel application.
> >
> > The decompression statistics contain one line per packet that is received
> > through the ROHC tunnel. The fields on every line are in order:
> > - the sequence number of the packet (this sequence may eventually
> overflow
> > and the result is undetermined),
> > - the total number of packets that were not correctly received (packets
> > lost on the network and packets that the ROHC library failed to
> decompress
> > correctly),
> > - the total number of packets that were lost on the network,
> > - the total number of packets that the ROHC library failed to decompress
> > correctly.
> > These fields are printed by the "print_decomp_stats" function in the
> source
> > code of the tunnel application.
> >
> > --
> > You received this question notification because you are a member of ROHC
> > Team, which is an answer contact for rohc.
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~rohc<https://launchpad.net/%7Erohc><
> https://launchpad.net/%7Erohc>
> > Post to : <email address hidden>
> > Unsubscribe : https://launchpad.net/~rohc<https://launchpad.net/%7Erohc><
> https://launchpad.net/%7Erohc>
> > More help : https://help.launchpad.net/ListHelp
> >
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

I do not think it is the sequence overflow, because you have to send much more packets than that to reach it.

I tried to reproduce the problem you describe but failed. What are the options you give to rohctunnel ?

If you are able to reproduce the problem, could you run the rohctunnel command as follow and send me the debug.log file ? If the debug.log file is large, send me only the lines from the beginning up to the line that starts with 65535.
  rohctunnel [your options here] >debug.log 2>&1 3>&1 4>&1

Didier Barvaux
Viveris Technologies

Khaan (pizwan80) said : #5

Thanks Didier Barvaux, that solved my question.

Khaan (pizwan80) said : #6

I am testing rohc-1.3..1 test with ./test

I have gone through the program but couldnt run any example from the test,

Can someone post some sample commands with ./test with say sample pcap name "source.pcap" having IPV4/IPv6 stream flow.

I want see/test available tools and options for analysis.

with kind regards,
Shaan

I can run a test with the following command:
  $ ./test/test smallcid ./test/report/samples/ipv4/icmp/source.pcap

For other options, run the program with -h:
  $ ./test/test -h
It will print the usage of the program.

Regards,
Didier

Khaan (pizwan80) said : #8

I tried the following

./test/test smallcid ./test/report/samples/ipv6/ipv6/udp/source.pcap -o
./test/report/samples/ipv6/ipv6/udp/output.pcap

Output pcap format is not as the input. Wireshark is unable to recognize the
format of output packets. I assume output pcap contains packets from flow A
and B both?

for my case, can you please guide me how can I capture the output of
compressor 1 in pcap format, so that I can compare them with input packets.

with kind regards,

Shaan

On Fri, Jul 22, 2011 at 6:31 PM, Didier Barvaux <
<email address hidden>> wrote:

> Question #85577 on rohc changed:
> https://answers.launchpad.net/rohc/+question/85577
>
> Status: Open => Answered
>
> Didier Barvaux proposed the following answer:
>
> I can run a test with the following command:
> $ ./test/test smallcid ./test/report/samples/ipv4/icmp/source.pcap
>
> For other options, run the program with -h:
> $ ./test/test -h
> It will print the usage of the program.
>
> Regards,
> Didier
>
> --
> You received this question notification because you are a member of ROHC
> Team, which is an answer contact for rohc.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~rohc
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~rohc
> More help : https://help.launchpad.net/ListHelp
>

Shaan,

> Output pcap format is not as the input. Wireshark is unable to recognize the
> format of output packets. I assume output pcap contains packets from flow A
> and B both?

No. If you run the ./test/test program with the -h option, there is a small help message saying:
  -o output_file save the generated ROHC packets in output_file (PCAP format)

The -o option is for writing the ROHC packets into a PCAP capture, not the decompressed
IP packets.

> for my case, can you please guide me how can I capture the output of
> compressor 1 in pcap format, so that I can compare them with input packets.

The output of compressor 1 is ROHC packets. So you can not compare them directly with
the input IP packets. You may however compare their lengths to measure the compression
gain. The output PCAP file contains twice more packets than the input capture (flow A and
flow B).

Regards,
Didier

Can you help with this problem?

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

To post a message you must log in.