TCP ACK number scaling
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
rohc | Status tracked in Rohc-main | |||||
Rohc-1.7.x |
Won't Fix
|
Medium
|
Didier Barvaux | |||
Rohc-main |
Fix Released
|
Medium
|
Didier Barvaux |
Bug Description
Didier,
I compared the compressor output
to see how my compression ratio is.
I found some differences...
To see what is going on, I feed the RoHC
pcap from the test directory into your deomp.
You have a great diagnostic debug output.
And I found this:
[DEBUG] [d_tcp.c:2353 d_tcp_decode_
[DEBUG] [d_tcp.c:2365 d_tcp_decode_
I looks like, that you are using the payload size for scaling.
This values is used for the seq_number scaling, but not for the ack_number:
The compressor MAY use the scaled acknowledgment number encoding;
what value it will use as the scaling factor is up to the compressor
implementation. In the case where there is a co-located decompressor
processing packets of the same TCP flow in the opposite direction,
the scaling factor for the sequence number used for that flow can be
used by the compressor to determine a suitable scaling factor for the
TCP Acknowledgment number for this flow.
If I understand this correct, I can use the seq_number scaling factor
from the opposite direction compression, if available. This could be
the payload size. But it looks like, that the compressor transmits the
default value 0 for the ack_stride (for what reason ever).
INITIAL {
ack_stride =:= uncompressed_
}
[DEBUG] [d_tcp.c:1549 d_tcp_parse_CO()] found 16 bits of sequence number encoded on 2 bytes
[DEBUG] [d_tcp.c:1570 d_tcp_parse_CO()] found 0 bits of acknowledgment number encoded on 0 bytes
[DEBUG] [d_tcp.c:1585 d_tcp_parse_CO()] found 16 bits of ACK stride encoded on 2 bytes
[DEBUG] [rohc_traces_
[DEBUG] [d_tcp.c:2257 d_tcp_decode_
[DEBUG] [d_tcp.c:2276 d_tcp_decode_
[DEBUG] [d_tcp.c:2353 d_tcp_decode_
[DEBUG] [d_tcp.c:2365 d_tcp_decode_
This is the rohc packet, where immediately after
the seq_num the ack_stride follows:
[DEBUG] [rohc_traces_
68 c0 <- seq_number 16bit 0x68c0
00 00 <- ack_stride 00 00
01 5e 25
but
[DEBUG] [d_tcp.c:2365 d_tcp_decode_
Code:
/* compute scaled acknowledgement number & residue */
if(payload_len != 0)
{
decoded-
decoded-
rohc_
"* payload size (%zu) + residue (0x%x)",
}
This look wrong for me. (The "decoded->seq_num" in rohc_decomp_debug
also, copy/paste)
If have no test, because I have no ack_stride value, because I have no
opposite decomp associated.
Instead of payload_len there should be decoded->ack_stride or
bits->ack_
In short:
Maybe compressor bug, sending ack_stride 0.
decomp uses payload_len for scaling ACK num as default instead of ack_stride.
Looks like a copy/paste issue from seq_number handling...
Could you please comment?
Best,
Klaus Warnke
Klaus,
Scaled ACK number was not fully implemented. Some of the code was indeed copy/paste from the scaled sequence number.
I fixed the scaled ACK implementation in the dev_fuzzing_ decompressor on the 11th of October. Your bug report looks like you tested with the master branch or maybe a prior version of the same branch. Could you tell me if the fix works for you?
The fix is located there on branch dev_fuzzing_ decompressor: /github. com/didier- barvaux/ rohc/commit/ 0a708940627ad9e 20ff7f35df92900 15ec017b3e
https:/
Regards,
Didier