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:[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

Reply via email to