Didier:
Yes, the retransmits are from the TCP layer. My point was we only see the
ROHC problems show up when we stress-load the transmission
and causing drops and retransmits at the TCP level.
I have captured the two main issues we have encountered. Both, I think,
have to do with the option list not being coherent.
The first case occurs in the TCP_OPT_SACK case in the tcp_decode_irregular_tcp
routine. The current option list contains
0x01 0x01 0x08 0x01 0x01 0x05 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
But the rohc packet has no data after the timestamp (0x08). So, a call to the
tcp_opt_sack routine returns the
ptr having been advanced, but no processing of the sack option is done, because
the discriminator value is 0. I
added the following check in tcp_opt_sack routine, but I think the problem is
with the incorrect option list, and the
fix should be there.
discriminator = *ptr;
/* Add check */
if (discriminator < 1)
return(ptr);
ptr++;
The other issue is sometimes an ACK has additional data after the SACK option.
I think that has to do with the incorrect
option list, also. Here is an example:
Incoming ROHC packet (supposed to be a SACK):
0xfa 0x8f 0xf4 0x00 0xb2 0x6f 0x83 0x56
0x4a 0x27 0xd8 0x29 0x1d 0x19 0xed 0x85
0x28 0x49 0xc5 0xba 0x4a 0xc5 0xba 0x4a
0x01 0x0b 0x50 0x05 0xa8
After decompression:
doff = 8 len = 41
0x13 0x88 0xd9 0x03 0x6f 0x83 0x56 0x4a
0x27 0xd8 0x1d 0xcd 0x80 0x10 0x1a 0x19
0x28 0x51 0x00 0x00 0x01 0x01 0x08 0x0a
0x00 0x05 0xba 0x4a 0x00 0x05 0xba 0x4a
0x02 0x1c 0x48 0x05 0xa8 0x0b 0x50 0x05
0xa8
There are 9 additional bytes at the end
that are not decompressed, because the
option list stops at the timestamp.
The option list:
0x01 0x01 0x08 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Again, these occurs only when there is heavy load.
Thanks in advance.
TW
-----Original Message-----
From: Rohc [mailto:[email protected]] On
Behalf Of Didier Barvaux
Sent: Tuesday, April 08, 2014 4:40 AM
To: [email protected]
Subject: Re: [Rohc] ROHC TCP dynamic field changes
Hello,
> The drops and retransmits are mostly after ROHC compression.
The ROHC protocol shall handle fine drops (ie. it shall not cause more drops
than the dropped packets) if the drop level is not higher than the level of
robustness you configured for the ROHC compression.
There are several parameters that may decrease or increase the ROHC
robustness:
- the width of the W-LSB window: you may configure it with the
rohc_comp_set_wlsb_window_width() function [1].
- the period of IR and FO refreshes: you may configure it with the
rohc_comp_set_periodic_refreshes() function [2].
- the number of list transmissions: you may configure it with the
rohc_comp_set_list_trans_nr() function [3].
Currently, for the TCP profile, only the width W-LSB window will have some
impact.
[1] doc for rohc_comp_set_wlsb_window_width():
https://rohc-lib.org/support/documentation/API/rohc-doc-1.6.1/group__rohc__comp.html#ga2b68070dddbc038cd55490952a7b3fa4
[2] doc for rohc_comp_set_periodic_refreshes():
https://rohc-lib.org/support/documentation/API/rohc-doc-1.6.1/group__rohc__comp.html#ga4e060551452e329ff628cd0be7160a2b
[3] doc for rohc_comp_set_list_trans_nr():
https://rohc-lib.org/support/documentation/API/rohc-doc-r1027/group__rohc__comp.html#ga32608bc06e1b0d1656e463eeb1ccbd7f
For retransmissions, I'm not sure to understand you. The ROHC protocol doesn't
retransmit packets. The retransmissions are caused by the TCP stacks on the
emitter or receiver sides. Maybe the ROHC library is not robust enough to
handle such retransmissions however. Send me a network capture of the
uncompressed stream and of the compressed stream, so I can diagnose the problem.
> We are using network containers to simulate compressor and
> decompressor nodes. I notice the retransmits are the compressed
> packets. I am looking into context management now. Suppose we want
> to simulate a group of nodes configured with ROHC. We would need to
> create a different context for each node, since we are compressing and
> decompressing hop-by-hop. We port the ROHC-lib into the kernel, and
> that is a single driver image used by all the simulated nodes.
> What is the best strategy to create a context for each simulated node?
> Are there handles in the ROHC-lib that we can use, such as node-id's
> for contexts?
One instance of ROHC compressor defines one internal context per stream.
Every TCP connection is allocated a different ROHC context for example.
So, every node with its own IP address should use its own ROHC contexts. They
won't mix together.
Another way is to create a ROHC compressor per node. This way the nodes don't
share the same ROHC compressor.
Did you used the Linux module provided with the ROHC library?
Regards,
Didier
_______________________________________________
Mailing list: https://launchpad.net/~rohc
Post to : [email protected]
Unsubscribe : https://launchpad.net/~rohc
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~rohc
Post to : [email protected]
Unsubscribe : https://launchpad.net/~rohc
More help : https://help.launchpad.net/ListHelp
