Optimistic Approach issue seq_number
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
rohc | Status tracked in Rohc-main | |||||
Rohc-1.7.x |
Won't Fix
|
Medium
|
Didier Barvaux | |||
Rohc-2.0.x |
Confirmed
|
Medium
|
Didier Barvaux | |||
Rohc-main |
Confirmed
|
Medium
|
Didier Barvaux |
Bug Description
Didier,
I analysed
non_regression/
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_
[DEBUG] [d_tcp.c:3313 d_tcp_update_
[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_
[DEBUG] [d_tcp.c:3313 d_tcp_update_
[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_
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?
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