[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages
Title: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages
Resend
(original message exceeded 40 KB limit, so I removed older discussion
texts.)
Zhigang
Mark,
This
is exactly the concern I have regarding the SigComp performance implication. I
see this as a question of *what* states to create. More precisely, a compressor
should create only "useful" state(s) from the text part(s) of a message while
avoiding creating "garbage" state(s) from the binary part(s).
(Of
course, it's possible that the binary part may also repeat across
messages and thus become useful. But I wouldn't go there for
simplicity.)
So,
how can a compressor achieve that? Below are ideas I can think
of. If they are correct, I can compile more "formal" text to be added to the
SigComp user guide.
There
are two steps involved. First, the compressor needs to know if current
message to be compressed contain binary parts, and if yes, where they are
located in the message. Second, the compressor needs to make sure it can
selectively create states on the decompressor side.
For
the first step, the best thing can happen is that the application (SIP
in this case) gives hint to sigcomp compressor. This is possible, since it
is a matter of local interface between application and sigcomp layer within
the same endpoint. Otherwise (i.e. no help from application), the compressor
has to figure it out by itself. In general, this seems to be a difficult problem
to solve (if possible at all). But there are a few simple and practical
approaches one can consider.
For
example, the compressor can check the compression ratio after compressing the
message. If it is close to 1, that is a hint that the current message
probably contains large binary content. The compressor can choose not to create
any state from current message. However, the compressor may miss a small text
segment in the message that turns out being repeated later in the subsequent
messages. The positive side is that at least the compressor can avoid creating
"garbage states".
Another factor to make a compressor's (or rather implementer's) life
easier: we can assume that application messages have two parts,
namely, a UTF-8 encoded part at the beginning followed by a binary part. (Note
this is the case at least for SIP.) Then, the compressor can identify the UTF-8
part (by parsing) and use it to create state. This also has a
good side-effect: compressor can avoid compressing the remaining
binary part.
Now to
the second step: creating state on decompressor side. One issue I see is the
limitation of decompression memory. On the decompressor side, the large binary
content may overwrite text content previously stored in the ring/history buffer
(part of the UDVM buffer). One solution is that the compressor should
"segment" one large application message into multiple sigcomp messages, so that
one of them contains only text data. This avoids the overwriting problem.
(Note: I don't think this works for SigComp over UDP. But on the other
hand, large SIP messages must be carried over TCP, not UDP.)
BR,
Zhigang
Richard, all,
The issue I would like to see addressed is as follows:
The text part of SIP/SDP is obviously highly compressible
using very simple algorithms which refer back to previous parts of the
message/earlier messages. In fact, subsequent messages in a SIP dialog seem to
consist almost entirely of repeated text from previous messages.
So, it seems important to me that large binary content in SIP
messages does not destroy state that will be useful in compressing subsequent
messages.
In a wireless environment, the principle advantage of
compression is reduction in the time taken to actually send the message over
the wireless link (this may even be more important than the overall reduction
in signalling bandwidth).
Now if the message contains large binary content, then of
course we are 'out of luck' on the message transfer time stakes, but this
shouldn't affect subsequent messages.
I believe we should document recommendations to SIGCOMP
compressor designers to ensure this aspect is not overlooked (although it is
not immediately clear to me how the compressor (being unaware of the SIP
message structure) might achieve this.)
Is this something that would be appropriate to item 4 below
?
Regards...Mark