Subject: [rohc] doubt in sigcomp decompression buffer

From: Rasheed Ahammad S <[email-masked]>
Date: Thu, 8 Jun 2006 11:21:56 +0530

Hi ROHCians,

I have the following doubts regarding the decompression buffer.

1. End Point A  uses compression algorithm of his own choice and sends the 
sigcomp message to End Point B. How much decompression buffer  B should 
allocate in order to successfully decompress the message. B is not aware 
of the compression algorithm used at  A and also its not aware of the 
compression ratio. If B allocates buffer of its choice..then there is 
chance of buffer overflow in case the decompressed message is bigger than 
the size of the allocated buffer.

2. RFC 4077 discusses this problem in OUTPUT OVERFLOW  as one of the 
reason codes for the failure. It means in our scenario when the 
decompression buffer overflows at  B it will form the NACK message with 
the reason code as OUTPUT OVERFLOW and send it to A. But the RFC does not 
discuss about how this problem should be recovered at end point B. How 
much decompression buffer  B should allocate for the next messages from A. 

Also, what end point A has to do when it receives  NACK message with 
OUTPUT OVERFLOW as the reason code.

The decompression buffer is not derived from any of the sigcomp 
parameters. So, there is no way that end point A can inform the end point 
B to increase its decompression buffer.

Regards,
Rasheed
Ext: 9113

***********************  FSS-Unclassified   ***********************

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Cristian Constantin <[email-masked]>
Date: Thu, 8 Jun 2006 13:55:51 +0000

> the size of the allocated buffer.

cristian: if you refer at the internal udvm buffer used for
decompression itself: overflow no bec. it's circular; more like overwrite. 
A should send the bytecode that runs in the minimum dms provided at B 
(for ims: 8k); the bytecode sent by A sets up the circular buffer.

for not overwriting already decompressed info you have to know for
example how much your decompression algo decompresses in "one"
decompression operation (i.e. by deflate what is the max length of the 
string that was matched in the window.)

> B to increase its decompression buffer.

cristian: now I think you refer to the memory where the decompressed
message is stored... rfc3320 says that OUTPUT causes problems when it
outputs more than 64K (it is not allowed to do it)
either you set it directly to 64 K for each and every udvm instance; or
you dynamically increase it until you reach that value. (on B)

bye now!
cristian