rohc team mailing list archive

["Wong, Tak - 0665 - MITLL" <Tak.Wong@xxxxxxxxxx>]

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:rohc-bounces+tak.wong=ll.mit.edu@xxxxxxxxxxxxxxxxxxx] On Behalf Of Didier Barvaux
Sent: Tuesday, April 08, 2014 4:40 AM
To: rohc@xxxxxxxxxxxxxxxxxxx
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     : rohc@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~rohc
More help   : https://help.launchpad.net/ListHelp