Subject: [rohc] RE: More on USD upload

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Fri, 9 Sep 2005 14:59:22 +0200

I don't have any particular size in mind but I think that if you want to use only USD (no dynamic/shared compression) then for efficiency reasons it should be possible to utilize the entire DMS.
BR
Jan

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: den 9 september 2005 14:52
To: Jan Christoffersson (LU/EAB)
Cc: Carsten Bormann; Pekka Pessi; rohc
Subject: Re: More on USD upload

So -- how big do you think a USD should be?

Gruesse, Carsten

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 12 Sep 2005 16:35:37 +0100

Hi Jan, all,

Coming slightly late into this discussion, here's my two penn'orth:

1) In the calculations below, no room is left for the bytecode and basic
running of the UDVM - surely the calculation is actually:

	2*USD = DMS - 2*bytecode - message length - 128 (lowest bytecode
upload at address 128)

(assuming that the USD goes into the circular buffer and that the
circular buffer immediately follows the bytecode)

2) As you say, the implementer's guide discusses the restriction that a
2K DMS places on uploading bytecode.  It also states "To address this
problem, those mandating the use of Sigcomp should also provide further
specification for their application that mandates the use of an
appropriately sized DMS."

The PoC specification mandates 4K DMS; IMS (3GPP TS 24.229) mandates 8K
DMS and the currently expired SigComp for SIP draft also stated 8K DMS
(in its last version).  Are you envisaging a use of SigComp where the
DMS really remains at 2K?   Using the calculation above, bytecode length
of 300 bytes and message of 400 gives:

	2* USD = DMS - 1128 so even with only 4K DMS you can have a 1400
byte USD.

3) How much SMS are you assuming?  If you have a USD much larger than
1400 bytes, then surely you risk being restricted by SMS not DMS?  The
PoC specification and the expired SigComp for SIP draft both say minimum
SMS 2K and IMS (24.229) says 4K.

4) You mention the time critical aspect of uploading a USD.  In my
understanding (feel free to correct it :-) ), assuming that a
compartment lasts for the duration of a registration, you can't create
state prior to registration (for security reasons) and registration is
not time critical (or at least is far less time critical than call
setup).  So, what's wrong with including the USD with the compressed
REGISTER message (i.e. the first message SigComp sees)?

5) If you put the dictionary in a SIP header, surely you have the same
problem - it's just that your compressed message is larger and you only
count the USD once (admittedly you'll get some benefit from compressing
the SIP message against the dictionary or vice versa, but not
necessarily enough)?

Best regards,

Abbie

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jan Christoffersson (LU/EAB)
> Sent: Friday, September 09, 2005 1:46 PM
> To: Pekka Pessi; Carsten Bormann; rohc
> Subject: [rohc] More on USD upload
> 
> 
> Hi,
> to illustrate the need for an out-of -band USD upload message 
> consider the following example of the inefficiencies involved 
> in uploading a USD state.
> 
> Suppose we have a 2K DMS and that the size of 
> bytecode+compressed message is 500 bytes (assume this size is 
> static for simplicity). This leaves 1500 bytes that can be 
> used for the USD. The question is how do we upload a 1500 
> bytes USD? It is only possible to upload 750 bytes with the 
> current message since we need two copies of the uploaded 
> state (one appended to the message and one for the circular buffer).
> 
> If we want to continue to upload the rest of the USD with the 
> next message, then only 375 bytes can be uploaded since we 
> now have 2000-500-750=750 bytes available for the two copies 
> of the uploaded part. Continuing in this way, we can upload 
> 187, 93, 46 and so on bytes with consecutive messages. Of 
> course it will not take forever but the example illustrates 
> the inefficiencies involved.
> 
> What I think could be important benefits with an out-of-band 
> upload mechanism is that it could be made independent of the 
> DMS size. It should also be made independent of the link MTU 
> (which typically limits the SIP messages size to 1300 bytes). 
> Hence, it should be possible to upload a USD in one message, 
> before the time critical signalling.
> 
> BR
> Jan
>

---

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Wed, 14 Sep 2005 09:31:38 +0200

Hi Abbie,
comments inline,

BR
Jan

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: den 12 september 2005 17:36
To: Jan Christoffersson (LU/EAB); Pekka Pessi; Carsten Bormann; rohc
Subject: RE: [rohc] More on USD upload

Hi Jan, all,

[Jan] Yes, assuming that the byte code is uploaded at the same time as the USD, this is true. This makes the maximum size of the USD even smaller than in my computation.

[Jan] Yes, 1400 bytes may seem enough for a USD but I think it may not be. For algorithms such as deflate where strings are matched it is not good enough to have all SIP words in a dictionary (like in the static dictionary), much better performance is obtained if longer strings are put in a dictionary, e.g. parts of messages (INVITE, 200ok, SDP bodies etc). There are also SIP messages that are not time critical but still would benefit from compression such as Presence signalling. The SIP messages may also contain XML bodies for presence. Actually I think there are a lot of things that could be useful in a USD.

[Jan] I've been assuming that the SMS is large enough for the DMS, i.e. of the same size.

[Jan] There is absolutely nothing wrong with this! On the contrary, it is the preferred way to upload the USD. My concern has been that it may not be possible to upload the entire USD in one message.

Best regards,

Abbie