rohc team mailing list archive

[Didier Barvaux <didier@xxxxxxxxxxx>]

Hello,

>     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.

OK.


>     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

Are those bytes the TCP irregular chain of the ROHC packet, or the TCP
options of the uncompressed packet? If those bytes are part of the
uncompressed packet, the timestamp option looks malformed.


> 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'm afraid I don't understand you well. The irregular encoding of the
timestamp option cannot be 0-byte length (it may encoded from 2 to 8
bytes). And, why the tcp_opt_sack routine read some ROHC bytes? Did you
mean the tcp_opt_ts routine instead?



> 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

Are those bytes the TCP irregular chain of the ROHC packet, or the TCP
options of the uncompressed packet? If those bytes are part of the
uncompressed packet, the timestamp option looks malformed.


Regards,
Didier