Subject: [rohc] More comments on sigcomp-05

From: [email-masked]
Date: Mon, 25 Mar 2002 20:55:34 +0100

Hi ROHC WG and Zhigang,

 I've been following the discussions lately and I have some comments regarding the -05 draft. New issues are marked with my name for later discussions.

sugar-1: Literals: Wouldn't it be good to have short forms of small negative numbers (65xxx-65535) in literals and just as for multitype? For example 11100000 nnnnnnnn: 65280-65535, or 00xxxxxx: (0-64) and 01xxxxxx: 65472-65535.

sugar-2: 9.3.1 states for JUMP instruction: "Note that if the address (specified as a delta from the address of the JUMP instruction) lies beyond the overall UDVM memory size then decompression failure occurs." For clarification should be added something like: "unless memory_address_of_instruction+delta>65535 where it is truncated modulo 2^16. This allows for backward jumps as well."

sugar-3: Parameter CALL (9.3.3): it would be useful to add PUSH (%value) and POP ($address) for handling the stack. This would allow for passing parameters to functions and also for recursive function calls. By the way, do we have a maximum stack size defined?

sugar-4: Having a default address in SWITCH instruction (9.3.4): Maybe more graceful than issueing decompression failure right away if the value is out of range.

STATE_FREE: I think it is very important in 3GPP from the memory usage point of view both for the terminal, which may have a limited amount of memory and the P-CSCF, which handles a large number of subscribers paralelly. The compressor would gain more control over the decompression process because it exactly knows the states it will never use again, so why store them at the other side? As for security concerns the worst case is that subsequent messages bail out with decompression failure and we have to use some kind of fallback (rollback,initial state,cleartext messages or whatever). Besides it is authorized anyways. It would also be good to have a STATE_FLUSH instruction, which would clear all the states that the endpoint has previously created. It could be issued when the session ends, so we wouldn't have to store the states until the next session but still keep the compression context.  Note, that from the compression efficiency point of view previous sessions contain much !
less useful data than previous messages of the same session (see 5.3 of the extended draft for comparison).

Eagerly waiting for the next drafts and the RFC...

Best Regards,
Robert

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

---

From: [email-masked]
Date: Tue, 26 Mar 2002 11:53:18 -0600

Hi Robert,

Thanks for the comments. Please see blow.

BR,
Zhigang

> sugar-1: Literals: Wouldn't it be good to have short forms of 
> small negative numbers (65xxx-65535) in literals and just as 
> for multitype? For example 11100000 nnnnnnnn: 65280-65535, or 
> 00xxxxxx: (0-64) and 01xxxxxx: 65472-65535.

The following (in Fig. 9) gives -32 and -4096. Note arithmetic
operation is performed modulo 2^16.

   111nnnnn                        N + 65504       65504 - 65535
   1001nnnn nnnnnnnn               N + 61440       61440 - 65535

> sugar-2: 9.3.1 states for JUMP instruction: "Note that if the 
> address (specified as a delta from the address of the JUMP 
> instruction) lies beyond the overall UDVM memory size then 
> decompression failure occurs." For clarification should be 
> added something like: "unless 
> memory_address_of_instruction+delta>65535 where it is 
> truncated modulo 2^16. This allows for backward jumps as well."

This is clarified at the beginning of section 9.3:

memory_address = (memory_address_of_instruction + delta) modulo 2^16

> sugar-3: Parameter CALL (9.3.3): it would be useful to add 
> PUSH (%value) and POP ($address) for handling the stack. This 
> would allow for passing parameters to functions and also for 
> recursive function calls. 

Actually, I'm thinking in the other direction. Why do we need 
(CALL, RETURN, statck_loaction) in the first place? A UDVM programmer 
can do the same trick using JUMP and LOAD. However, if we need
them for purpose of modular programming (perhaps also saving a
few bytes), I think PUSH and POP are useful to have. 

> By the way, do we have a maximum stack size defined?

No. I don't see why we need one.

> sugar-4: Having a default address in SWITCH instruction 
> (9.3.4): Maybe more graceful than issueing decompression 
> failure right away if the value is out of range.

How could we use the default address? It seems to me issuing
decompression failure is prudent. We cannot help if the
code is incorrect. It could be sent by an attacker.

> STATE_FREE: (snip) 

Yes, we will have STATE_FREE. Note that this is only a request by
the sending endpoint. It does not necessarily mean the state
is actually deleted by the receiver. E.g., the state may be "shared"
by different endpoints and can have a counter recording how
many remote endpoints are referring to it. It is only deleted
when the counter equals zero. Either way, the memory usage
number for the sender of STATE_FREE will be reduced. 

> It would also be 
> good to have a STATE_FLUSH instruction, which would clear all 
> the states that the endpoint has previously created. 

Not sure about this one. For security reasons, the sender of
STATE_FREE must indicate the state ID to be freed. It seems
STATE_FLUSH does not have this. I feel a bit uneasy here.

I think this may be something done by applications. If the application 
at one endpoint knows it will no longer talk to its peer application
at a remote endpoint, then it can release the memory allocated
for that remote endpoint.

> Eagerly waiting for the next drafts and the RFC...

Next version of drafts should be released on April 5.