Subject: [rohc] (remote) dms problem

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 29 Mar 2006 13:02:59 +0200

hi!

first of all one question: is any of the "additional" sigcomp
drafts/rfcs imposing some values for how much the dms of the udvm should
be when sigcomp is used with sip and dictionary(rfc3485)?

now assume the following scenario:

INVITE ----> P-CSCF ....(sigcomped INVITE)...> IMS terminal

the sigcomped INVITE is also the first sigcomp message the P-CSCF is
exchanging with the IMS terminal; so we can assume that the
P-CSCF has no clue about the udvm parameters the IMS is going to use
(i.e. does not know how much dms the terminal is going to allocate for
the udvm execution). suppose that the terminal is somehow using less
dms than: sizeof(rfc3485_dictionary)+sizeof(udvm_bytecode).
there are several options now:

1. the udvm bytecode checks somehow that the available dms is too low. 
it issues an error if that is the case: USER_REQUESTED? (in NACK parlance). 
again, depending on whether a NACK approach is used or an explicit ACK 
one, there are 2 options:
  a. (NACK) the error is reported back. no clue about the dms, though...
  (the only NACK error which is giving as a detail the dms is
  BYTECODES_TOO_LARGE and is triggered at the initialization of the
  virtual machine)
  b. (explicit ACK) for me it is not very clear what happens in this
  case; my guess is no packet is sent back...

2. the udvm does not check the available dms. a more or less
unpredictable error will occur or the decompressed packet will 
contain wrong bytes. if the error occurs:
   a. (NACK) the error is reported back. again no clue about the dms... 
   b. (explicit ACK) ???
if a malformed packet is passed to the SIP stack again nothing relevant
for sigcomp will happen; the remote sip will most likely retransmit the
INVITE but the same thing will happen again.

is it really so or is it something that I have missed when reading the
various rfcs/drafts??

waiting for your oppinion,
bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark" <[email-masked]>
Date: Wed, 29 Mar 2006 15:03:45 +0100

> cristian: if the dictionary is there why not making use of it? :-)
> so, the approach would be a compromise between the "initial" compressing
> rate and the udvm memory necessary for decompression.

If the dictionary is there, then it is entirely reasonable to make use of it.  However, as you point out, in a environment where a small remote DMS has to be assumed, then you may not be able to use all of the dictionary.  (This, I believe, is one of the reasons that the dictionary is split into parts: if you can't fit it all in, then use the bit(s) that contains the most common strings.)  It is probably better to sacrifice some compression efficiency than have a decompression failure!

But it still has to be a compressor-based decision, using the information that it has about the remote end, to make sure that everything fits within the available memory.

Of course, this sort of discussion was what motivated the 8k DMS in the SigComp/SIP draft...

Cheers,

Mark.