Subject: [rohc] Handling of error Cycles exhausted in sigcomp NACK

From: Rasheed Ahammad S <[email-masked]>
Date: Thu, 15 Jun 2006 14:44:11 +0530

Hi

In case of receiving the NACK with reason code CYCLES_EXHAUSTED..what 
action should be taken by the receiving end point in order to recover from 
this problem.

The scenario is:

A sends a Sigcomp message to endpoint B...now while decompressing the 
message the udvm cycles at B gets exhausted before successful 
decompression of the message...B will generate a NACK message with 
CYCLES_EXHAUSTED reason code and send it to A. Now what action should be 
taken by the endpoint A to overcome this problem...

Does the endpoint A need to change the bytecode which will consumes  less 
number of udvm cycles. Please clarify..

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, 15 Jun 2006 09:54:29 +0000

> taken by the endpoint A to overcome this problem...

cristian: theoretically change your compressor/decompression bytecode
such that it will run in less cpb. from a practical point of view there
is not much you can do about this...
adapting a certain compressor such that the decompressor will run in a
certain cpb does not seem trivial to me; I think that limiting the CPU 
cycles on the remote decompressor is some kind of defense against a DOS
attack (for example a decompressor is always exec. an infinite loop).
the case you are mentioning is a false positive (not an DOS but a real
decompressor is using too much CPU)

now, since you have brought this up, can someone please tell me what's
the magical 1000 in the formula:

maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
(rfc 3320 - 8.6.  UDVM Cycles)

bye now!
cristian

---

From: Cristian Constantin <[email-masked]>
Date: Thu, 15 Jun 2006 11:13:06 +0000

> is not much you can do about this...

cristian: one more thing; decreasing the compressor window (in the
case of dynamic compression) will lower the sigcomp "cycles" of the
decompressor as well (bec. it saves/loads less bytes)

> (rfc 3320 - 8.6.  UDVM Cycles)

cristian: is 1000 thought as the order of magnitude (in bytes) for the
states used by the compression algorithm?

bye now!
cristian