Subject: RE: [rohc] sigcomp issue cabo-11

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

> I.e., can we accept an implementation that always assembles a full
> message before starting the UDVM?  This would mean that a compressor
> implementation cannot rely on output being generated before the end of
> the input message is reached.  I'm not sure that fits your interesting
> model of TLS usage.

Carsten,

This is an interesting question - it depends on how we choose to define
the concepts of a "SigComp message" and a "SigComp session" in the context
of particular signalling applications.

My current assumption is that this will depend on the application security
mechanism. If security is provided by the application itself then I expect
one SigComp session to map onto exactly one application session, and one
SigComp message to map onto exactly one application message.

If security is provided by TLS I expect that one SigComp session will map
onto exactly one TLS session. However, I believe that a SigComp message
should be allowed to have an arbitrary length - it may correspond to the
entire TLS session, or it may be a standalone SigComp message that
provides feedback data only and does not carry application data at all.

In the above model the receiving endpoint can't buffer a full SigComp
message before starting the UDVM, but it can certainly buffer a full
application message (since there is no correlation between the two).
This means that the UDVM memory can be reclaimed between two application
messages, which provides similar benefits to the "instantaneous UDVM"
model used over UDP.

> We could bridge the gap by providing a "push" delimiter in the record
> marking scheme; this would make it clear that the compressor relies on
> the "persistent UDVM" model and that the UDVM needs to be started with
> the data up to the push.

I believe that the functionality of a "push" delimiter can already be
provided using the INPUT instructions.

The benefits of the "instantaneous UDVM" model can only be provided with
the co-operation of the sending endpoint, because they are only available
for certain types of compression algorithm. Stream-based algorithms (LZ77,
LZ78, LZW, DEFLATE etc.) use a constant amount of memory independently of
the application message boundaries, so there is no advantage in providing
a large UDVM core and then reclaiming this memory after each application
message has been decompressed.

With a block-based algorithm (e.g. Burrows-Wheeler) however, it is
possible to buffer an entire application message, decompress this message
and then reclaim most of the UDVM memory until the next message has fully
arrived. This can be achieved as follows:

1. The INPUT-OCTETS instruction can be used to obtain an entire application
   message, causing the UDVM to pause and wait until the message has fully
   arrived. Note that the length of the application message is carried as
   part of the compressed data (it is independent of the size of a SigComp
   message when running over TLS).

2. When the message has arrived it can be decompressed using all of the
   available UDVM memory.

3. The algorithm can place all of the data it needs to keep for the next
   application message in the low UDVM memory addresses, and it can set
   the memory it wishes to release to 0.

If a block-based algorithm of this nature is uploaded to the receiving
endpoint, any UDVM memory that it chooses to release between application
messages can be reclaimed and used elsewhere.

Note that the UDVM can still persist for the entire duration of a session,
but most of its memory can be reclaimed except for the "instantaneous"
period in which a complete application message is being decompressed.
This allows the receiving endpoint to offer a larger UDVM memory size
than would otherwise be possible.

The "push" delimiters are provided as part of the compressed data stream
by the algorithm itself (all block-based algorithms use delimiters of
some kind). Stream-based algorithms will generally not delimit the
individual application messages at all - this is useful because we can't
perform the "instantaneous UDVM" trick for an algorithm of this type, so
there is no point wasting bandwidth on delimiting the application
messages in this case.

Regards,

Richard

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Apr 2002 18:12:16 +0200

> any UDVM memory that it chooses to release between application
> messages 

Richard,

I'm not sure I understand this.
What do you mean by "releasing UDVM memory"?
We can't do this in the "persistent UDVM" model.

 > provided using the INPUT instructions.

No, because the functionality is exactly to start up the UDVM.
(Maybe you meant to say "we don't need the instantaneous UDVM model, 
because we have INPUT", but I understand that even less.)

So I still believe a "push" delimiter would be useful to indicate "yes, 
this app needs a persistent UDVM, so please start it now instead of 
waiting for the message-end delimiter".  Maybe there is another way to 
signal this -- being able to signal delimiterless UDVM-based processing 
would also allow to get rid of the byte stuffing needed otherwise.

Gruesse, Carsten

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