Subject: [rohc] sigcomp issue cabo-15

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 16 Apr 2002 20:19:44 +0200

Hi,

> decompression_memory_size differs from the proposed resolution,
> though (maybe I just don't understand 3.3.1; it's certainly not
> crystal clear).

My understanding is that decompression_memory_size, includes the former parameters "compressed-message-size" and "UDVM-memory-size" which would correspond to a input buffer and the UDVM byte-buffer (UDVM memory). So the only thing this excludes is the former parameter "decompressed-message-size". However, that could also bundle up with the others into the decompression_memory_size, by adding some text to section 3.3.1.

"The decompression_memory_size parameter specifies the amount of 
   memory available to decompress one SigComp message. A portion of this 
   memory is used to buffer a SigComp message before *and after* it is decompressed; 
   the remainder is given to the UDVM..."

> cycles_per_bit can only be 16 to 128; I believe lower values are
> required.  (And the default may need to be lower: As it stands, 12000
> bit messages can use up to 208000 cycles, that is quite a lot,
> considering that many server-side implementations may need a few
> hundred ns per cycle, and UE implementations easily can take several
> us.)

Hmm, what is a reasonable value for a deflate algorithm, with a compressed message of say 12000 bits?

BR
/Hans H 

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

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 17 Apr 2002 15:09:16 +0100

> My understanding is that decompression_memory_size, includes 
> the former parameters "compressed-message-size" and 
> "UDVM-memory-size" which would correspond to a input buffer 
> and the UDVM byte-buffer (UDVM memory).

Yes, we now announce both the compressed_message_size and the
UDVM_memory_size as a single decompression_memory_size parameter.
This is in line with the proposed resolution that we discussed at
Minneapolis.

> So the only thing this excludes is the former parameter 
> "decompressed-message-size". However, that could also bundle 
> up with the others into the decompression_memory_size, by 
> adding some text to section 3.3.1.

In the proposed SigComp-06 draft the decompressed_message_size is
not announced. The reason for this is as follows:

SigComp can control the amount of memory required by both the
compressed message and by the UDVM, so it can cope with changes
in the available memory by (e.g.) reducing the size of the circular
buffer. Therefore it is useful for the sending endpoint to receive
an announcement of these parameters.

However, SigComp has no control over the amount of memory needed to
buffer decompressed messages (as SigComp can't change the size of the
messages generated by the application). So there is no benefit to
announcing the decompressed_message_size supported by the receiving
endpoint as the sending endpoint can't do anything useful with this
information.

In fact, if the receiving endpoint is particularly memory-starved
then it can output the decompressed message directly into the memory
reserved by the signalling application itself. This avoids the need for
SigComp to provide its own buffer for decompressed messages altogether.

>    memory is used to buffer a SigComp message before *and after* it
>    is decompressed; the remainder is given to the UDVM..."

The memory used to buffer a decompressed SigComp message is not included
as part of the decompression_memory_size, because the sending endpoint
doesn't care how much memory has been provided for this task. As mentioned
above the memory might even come from the application itself.

> a compressed message of say 12000 bits?

Since DEFLATE is about the slowest algorithm around, the default value
for cycles_per_bit should be enough to decompress DEFLATE messages (plus
a reasonable margin of safety). DEFLATE needs roughly 1 - 8 cycles per
compressed bit depending on the compression ratio, so a default value of
16 cycles per bit seemed reasonable to me.

Note that a 12000 bit compressed message is rare - it will typically
occur only if the message is poorly compressed (in which case it will
need far less than the maximum available cycles_per_bit).

Regards,

Richard

---

From: [email-masked]
Date: Thu, 18 Apr 2002 19:01:22 -0500

[Carsten wrote:]

> Arguments for setting it to 0:
> 
> -- Remember that state_memory_size is per compartment/session.
>    There may be many implementations that don't have a known upper
>    bound on the number of sessions/compartments they have to support....

Yes, a good argument for a server talking to millions clients.
 
>  -- on the other hand, a host may simply not *have* any stable 
> storage that would survive long enough.)

I'm lack of imagination here. In practice, what kind of host that
would be?
 
> Arguments for setting it to a small number like 2048:
> 
> -- The first message in an exchange can already download state; this
>    allows to improve compression significantly after the first
>    roundtrip.  (Otherwise, the improvement only comes after the second
>    roundtrip.)  This is essentially the "avoid negotiation" argument.

Yes, I remember this is how we started.

> A "default" different from zero could be an application specific
> "default" -- so, even if the general-Internet sigcomp sets the
> "default default" to zero, 3GPP could always mandate a different
> default, or derive the actual state_memory_size value from any 3GPP
> specific discovery process.

This makes me think if we need negotiation after all. Otherwise, we may 
have 3GPP default, non-3GPP default, and what happens if 3GPP host 
talks to non-3GPP hosts, etc.? On the other hand, since we don't even 
have a solution for SigComp discovery in general, this might be the
only (practical) way out.

Zhigang

---

From: [email-masked]
Date: Thu, 18 Apr 2002 19:18:31 -0500

> This is in line with the proposed resolution that we discussed at

Yes, that helps the goal of reducing the number of parameters.
However, that makes implementation tricky on the receiver end. 
It has to expect any combination of compressed_message_size 
and UDVM_memory_size that totals to 2048 octets. The situation
is worsen by the fact that the former is for decompressor dispatcher 
and the latter is for UDVM. How can one avoid having two buffer
with 2048 octets each?

Also, two related questions:
- What will be the "special value" for UDVM_memory_size in Figure 5?
- What does decompression_memory_size mean exactly for "stream-
compression" case?

Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 22 Apr 2002 11:00:12 +0100

Hi,

If it's important to have a high compression ratio after one RTT, the
compressor can just download and save some state without checking that
sufficient state memory is available. The return message will include
a state_memory_size parameter; if this is set to 0 then the compressor
knows that the state creation request has failed and will not attempt
to access the state item.

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 22 Apr 2002 12:01:12 +0100

> and UDVM_memory_size that totals to 2048 octets.

Hi,

In practice this should not cause any implementation problems. If an
endpoint receives a compressed message of n octets, this message is
copied into the reserved block of 2048 octets and the remaining
2048 - n octets are given to the UDVM.

> The situation is worsen by the fact that the former is for
> decompressor dispatcher and the latter is for UDVM.

The decompressor dispatcher and the UDVM are logical entities only; the
fact that both are drawing from a common pool of memory should not cause
any problems.

> How can one avoid having two buffer with 2048 octets each?

I don't believe that it is particularly difficult to use the same block
of 2048 octets to store both the compressed message and the UDVM memory.
However, if the endpoint is not memory-starved then a separate fixed-size
block of memory can easily be allocated to each one.

> - What will be the "special value" for UDVM_memory_size in Figure 5?

The UDVM_memory_size in Figure 5 is just set to the size of the UDVM
memory in octets (taken modulo 2^16).

> - What does decompression_memory_size mean exactly for "stream-

In the stream-compression case we don't know the size of each compressed
message in advance, so we just divide the total decompression memory
equally between the input buffer and the UDVM. So if the total memory
available is 2048 octets as above, the input buffer for the compressed
data is allocated 1024 octets and the UDVM is allocated 1024 octets.

Regards,

Richard

---

From: [email-masked]
Date: Mon, 22 Apr 2002 14:01:17 -0500

> to access the state item.

That works. However in case of 0 state_memroy_size, that will cost
~1K bytes overhead across the air for nothing. I still think we
can set the minimum to 1024 (with encoding 000). If that is too
much for a host, it should not use SigComp in the first place. 
It can use IPcomp.

BR,
Zhigang

---

From: [email-masked]
Date: Mon, 22 Apr 2002 15:09:08 -0500

> 2048 - n octets are given to the UDVM.
(snip) 
> fact that both are drawing from a common pool of memory should not cause

OK. In that case, there is no problem on the decompressor side. 

However, on the compressor side, do we have a chicken-egg problem?
The compressed message size depends on which state can be used.
On the other hand, which state can be used depends on UDVM memory
size which in turn depends on compressed message size. Of course,
the compressor can do trial-and-error. But if we have a "standalone" 
UDVM memory size, the compressor can have a fixed picture of available
UDVM memory.

> memory in octets (taken modulo 2^16).

which is (2048 - n) in above example? 

> data is allocated 1024 octets and the UDVM is allocated 1024 octets.

Does every compressor performing stream-compression must assume this? 
Considering this and above, do we really gain much by combining
compressed_message_size and UDVM_memory_size in one parameter? 

BR,
Zhigang

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Mon, 22 Apr 2002 23:24:29 +0200

> can set the minimum to 1024 (with encoding 000). 

I think that we should have a default of 0 state_memory_size, with the motivation given by Carsten and Richard.

> If that is too

Well, wouldn't you then have the discovery problem?

BR
/Hans H

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Mon, 22 Apr 2002 23:46:03 +0200

Hi,

Perhaps I'm way out on deep water but is it possible to change cycles_per_bit in case we find that unreasonable high after interOp tests have started? Or should we do the opposite put a lower value say cycles_per_bit: 8 and increase it if interOp tests indicate the need?

Good night,
/Hans H

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 23 Apr 2002 10:18:31 +0100

> ~1K bytes overhead across the air for nothing.

Hi,

I don't see why any bandwidth needs to be wasted if the state_memory_size is 0.
Most of the ~1K state item is taken up by text strings from the decompressed
message; these have to be transmitted regardless of whether they will be saved
as state or not.

> I still think we can set the minimum to 1024 (with encoding 000).
> If that is too much for a host, it should not use SigComp in the
> first place. It can use IPcomp.

Choosing between SigComp and IPcomp would require a discovery mechanism, which
I'm keen to avoid if possible.

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 23 Apr 2002 14:02:49 +0100

Hi,

We should probably err on the side of caution and set cycles_per_bit
to a high value rather than a low value. If the minimum value turns
out to be twice as much as is needed for DEFLATE then I can't see any
serious problems for implementers. However, if the minimum value
turns out to be less than is required to run a typical decompression
algorithm then we will be unable to upload many algorithms for a full
RTT while waiting for a more sensible cycles_per_bit to be announced
by the receiving endpoint.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 10:46 PM
> To: [email-masked]
> Subject: RE: [rohc] sigcomp issue cabo-15
> 
> 
> Hi,
> 
> Perhaps I'm way out on deep water but is it possible to 
> change cycles_per_bit in case we find that unreasonable high 
> after interOp tests have started? Or should we do the 
> opposite put a lower value say cycles_per_bit: 8 and increase 
> it if interOp tests indicate the need?
> 
> Good night,
> /Hans H
>

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 23 Apr 2002 15:42:14 +0200

> by the receiving endpoint.

This seems to be good reasoning. 

So is it ok to say the following then?

Proposed action: Resolution proposed in current editor's working document (This text seems to be sufficient.) 
Suggested default values seems to be well motivated. 

(Cut from previous mails)
"decompression_memory_size: 2048 octets
state_memory_size: 0 octets
cycles_per_bit: 16
SigComp_version: 0
locally available state: none"

BR
/Hans H

---

From: [email-masked]
Date: Tue, 23 Apr 2002 10:53:56 -0500

> Most of the ~1K state item is taken up by text strings from 
> the decompressed message; 

This is not necessarily true. The ~1K state can contain anything. 
Specifically, the compressor may want to pre-populate the
dictionary with text that not even appears in current message
on which the state creation request is piggybacked on. 

> Choosing between SigComp and IPcomp would require a discovery 
> mechanism, which I'm keen to avoid if possible.

What I'm trying to say is that one of the advantages of SigComp
over IPcomp is the dictionary based compression. And that is the
reason why a host chooses SigComp. Setting the default to 0
seems defeating the purpose of SigComp.

Re discovery, that is a separate issue. The general SigComp
discovery is an open problem anyway, regardless if IPcomp is 
in picture. (We managed to avoid it in 3GPP by mandating support 
for SigComp. But that is just a quick fix due to time pressure)

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 24 Apr 2002 16:31:48 -0500

> state_memory_size: 0 octets

I still believe the value should be 1024. 

- If the host is a client, 1 KB is not something too much to ask.
- If the host is a server, then 1KB per client should not be
a problem either. In practice, an administrator anyway needs to 
make provision for memory cost according to expected number of 
clients. 

> "decompression_memory_size: 2048 octets

No problem with the number itself, but has anyone checked on
the impacts of combining compressed message size and UDVM memory
size to the logic at compressor side (see below)?

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00448.html

BR,
Zhigang