Optimistic Approach issue seq_number

[Klaus Warnke]

Didier,

I analysed

non_regression/rfc6846/inputs/ipv4/tcp/swapped-ip-id/rohc_maxcontexts1_wlsb4_smallcid.pcap

For me is looks like, that the compressor immediately going from lsb to static compression.
For example:

[DEBUG] [rohc_decomp.c:779 rohc_decompress3()] decompress the 68-byte packet #5
[DEBUG] [d_tcp.c:1549 d_tcp_parse_CO()] found 16 bits of sequence number encoded on 2 bytes
[DEBUG] [d_tcp.c:2257 d_tcp_decode_bits()] TCP sequence number = 0x758946b0 (decoded from 16-bit 0x46b0 with p = 16383)
[DEBUG] [d_tcp.c:3313 d_tcp_update_ctxt()] sequence number 0x758946b0 is the new reference

[DEBUG] [rohc_decomp.c:779 rohc_decompress3()] decompress the 27-byte packet #6
[DEBUG] [d_tcp.c:1570 d_tcp_parse_CO()] found 16 bits of acknowledgment number encoded on 2 bytes
[DEBUG] [d_tcp.c:2257 d_tcp_decode_bits()] TCP sequence number = 0x758946dd (decoded from 16-bit 0x46dd with p = 16383)
[DEBUG] [d_tcp.c:3313 d_tcp_update_ctxt()] sequence number 0x758946dd is the new reference

[DEBUG] [rohc_decomp.c:779 rohc_decompress3()] decompress the 280-byte packet #7
[DEBUG] [d_tcp.c:1570 d_tcp_parse_CO()] found 0 bits of acknowledgment number encoded on 0 bytes
[DEBUG] [d_tcp.c:2264 d_tcp_decode_bits()] TCP sequence number = 0x758946dd (re-used from previous packet)

From #6 to #7 the seq_number stays unchanged.
But if the packet #6 gets lost, the decompressor has the seq_num value from #5.
Therefore I assume, the the compressor could not omit a static value direct after lsb compression.
It has to repeat the static value at least 4 times here (the size of wlsb window).

If I have a wlsb window size 4, then I have 4 possible reference values.
Therefore I assume that 1 out of 4 packets are transmitted successfully,
or at most 3 of 4 packets getting lost.
If I assume this for this wlsb reference value compression, it makes
sense to assume the same for the static fields (optimistic approach).
Therefore I have to repeat a static value 4 times until the
compressor is confident that the value is known by decompressor.

See also:

5.2.1.1. Optimistic Approach

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information. The optimistic approach is useful to
   ensure robustness when ROHC-TCP is used to compress packets over
   lossy links.

   Therefore, if field X in the uncompressed packet changes value, the
   compressor MUST use a packet type that contains an encoding for field
   X until it has gained confidence that the decompressor has received
   at least one packet containing the new value for X. The compressor
   SHOULD choose a compressed format with the smallest header that can
   convey the changes needed to fulfill the optimistic approach
   condition used.

Best,
Klaus Warnke

Btw: How could I run a specific test with full debug output?

[Klaus Warnke (k-warnke)]

I tested the OA stuff by dropping RoHC packets.
For example, for a optimistic approach repeat count of 1,
every information is repeated one time. And there are
two reference values in the WLSB.
Therefore I can drop every second packet without getting
any decompression failure.
If you have a OAR value of 2, it is sufficient to transmit
every third packet for a error free decompression.

Best,
Klaus Warnke

[Didier Barvaux (didier-barvaux)]

Klaus,

> Btw: How could I run a specific test with full debug output?

For the capture that you used for this bug report, run the following command from the root of the library sources:
$ ./test/non_regression/rfc6846/test_non_regression_ipv4_tcp_swapped-ip-id_maxcontexts0_wlsb4_smallcid.sh verbose

For more details refer to the wiki:
https://rohc-lib.org/wiki/doku.php?id=library-tests#running_one_specific_non-regression_test_manually

Regards,
Didier

[Didier Barvaux (didier-barvaux)]

Klaus,

You're right. There is a bug in function variable_length_32_enc() of the compressor. The comparison between new_value and old_value is wrong wrt OA. I'll fix it asap.

Regards,
Didier