rohc team mailing list archive

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

Didier:

    The drops and retransmits are mostly after ROHC compression.  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?

Thanks in advanced.

TW

-----Original Message-----
From: Rohc [mailto:rohc-bounces+tak.wong=ll.mit.edu@xxxxxxxxxxxxxxxxxxx] On Behalf Of Didier Barvaux
Sent: Sunday, April 06, 2014 8:03 AM
To: rohc@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Rohc] ROHC TCP dynamic field changes

Hello,

My answers below.


>     We have an implementation in the Linux kernel using the ROHC-lib.
> We've found a problem on the decomp side where the dynamic fields of
> a packet are changed, but the option list is not updated.   This
> occurs only when we push large-size packets (> 1024) as quickly as 
> possible, thus causing packet drops and retransmits.

Do the drops/retransmits happen before or after the ROHC compression?


> So, it seems like a retransmitted packet's options do not match the 
> option list on the decomp side.  My idea of a fix is on the comp side
> - when I detect a change in the dynamic parts, I should send an IR_DYN 
> to update the option list.

The compressor should indeed send more information about the changing options. Not necessarily in an IR-DYN packet however.


>  When I was looking at the d_tcp.c
> code,  I saw several places ifdef'd out with "TODO's"  that seem to do 
> similar things.  For example, the following snippet from the code:
> [...]
> Is the purpose of the above code to refresh the decomp side when 
> changes in the dynamic fields are detected? Have these TODO's been 
> completed?  What needs to be done to make it work?

The TCP profile is work in progress. The transitions between compression states is not fully written. Hence the commented code.

The compressor shall be able to handle your TCP stream fine even without the state transitions. It probably didn't detect one or more changes correctly and failed to use the required packet type.

If you're able to capture the faulty TCP stream, please send it to this mailing list*. We'll be able to improve the ROHC library.

Regards,
Didier

* if the PCAP capture is big (> 500KB), don't send it on the mailing
  list, upload it somewhere then post the link on the ML.