Subject: RE: [rohc] (remote) dms problem

From: "West, Mark" <[email-masked]>
Date: Wed, 29 Mar 2006 13:57:01 +0100

Hi Cristian,

I'm afraid that I don't really understand the problem...

The sending endpoint has to [try to] ensure that any message it sends will decompress.  So if you know nothing about the remote DMS, you have to assume that it is the minimum mandated value (e.g. 2k in base SigComp, 8k for SigComp/SIP, whatever-it-is for IMS).

[FWIW, the 8k for SigComp/SIP is stated in the SigComp for sip draft; I believe that IMS has mandated a lower value]

If you subsequently (via an advertisement in a response) find out that more resources are available, then you can make use of them.

In either event, you should not be relying upon making use of more resources than you know the UDVM has (so UDVM code should not need to try and check if there's enough room).

As to the comparison with "sizeof(rfc3485_dictionary)+sizeof(udvm_bytecode)", I don't see what impact the size of the dictionry has?  (Unless you are trying to load the entire dictionary into UDVM memory; but, again, this should be constrained by the compressor's conservative estimate of available resources).

Cheers,

Mark.

-----Original Message-----
From: Cristian CONSTANTIN [mailto:[email-masked]]
Sent: Wed 3/29/2006 12:02 PM
To: [email-masked]
Subject: [rohc] (remote) dms problem
 
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: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 29 Mar 2006 15:54:43 +0200

> [FWIW, the 8k for SigComp/SIP is stated in the SigComp for sip draft; I believe that IMS has mandated a lower value]

cristian: hi! didn't know about those 8K for sigcomp/sip; seems reasonable
(i.e. should not get you into trouble with the first packet, that is until
you find out what the real remote dms is)
have to check the IMS value though.
however I guess that the [try to] above is the trickiest part...

> As to the comparison with "sizeof(rfc3485_dictionary)+sizeof(udvm_bytecode)", I don't see what impact the size of the dictionry has?  (Unless you are trying to load the entire dictionary into UDVM…

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.

thanks a lot,
bye now!
cristian