rohc team mailing list archive

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

Hi Didier:

   I have some more information about the issues I have with our kernel implementation:

I have several network namespaces set up in a chain, so packets from one end will be transmitted to the receiver on the other end.
I have 2 simple tcp_server and tcp_client applications - the server listens on port 5000 and the client sends packets as fast as possible
to the server.   The transmission is 1-directional, from client to server.  The only packets coming back from the server are ACK's, specifically,
SACK packets.   I have modified the code to compress only packets from the client and leave the ACK's from the server in the clear.  There are
no issues with the compressed packets traversing over 5 namespace nodes in a chain.  Then I disable the compression on the sending client,
and enable the compression on the ACK's.  Then I see all the problems with the inconsistent option lists and packet lengths, as I explained
to you before.

Hope this additional information is helpful.

Kind regards,

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