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

From: "Price, Richard" <[email-masked]>
Date: Wed, 17 Apr 2002 12:04:38 +0100

> > > Would the suggested action cause any problems?
> > > If not why not just go ahead and use the lower memory if that
> > > would avoid a loop.
> >
> > I would suggest to go this way too. The only implication is that
> > the decompressor dispatcher needs to have a complete SigComp
> > message before invoking UDVM. But that is not a problem to me.
> 
> Yes (sorry, I considered but failed to document this implication).
> 
> It's not a problem for me, either.
> (It does remove some implementation flexibility for the TCP case,
> though.)

Hi,

The TCP case is something that hasn't received enough discussion on the
mailing list - so I've attempted to explain the two ways that we could
support TCP and why SigComp uses the more complex approach:

The simplest way to support TCP would be to just rely on the message
delimiters to convert a TCP stream into a series of distinct, bounded
messages. The receiving endpoint could then input an entire message
before it is decompressed.

The alternative approach is to allow the receiving endpoint to stream-
decompress a SigComp message (i.e. to input, decompress and output the
first part of a SigComp message before the remainder of the message has
even arrived). This is the approach currently used by SigComp (we first
took the simple approach but then changed to stream decompression in
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-udvm-00.txt).

The first approach is certainly simpler, but the second approach offers
significantly better performance because it takes into account the way
signalling applications make use of TCP.

In SIP for example, TCP support is provided to ensure that SIP can cope
with large application messages. It is mandatory to transport messages
larger than 1300 bytes using TCP (assuming an MTU of 1500 bytes), so
that fragmentation can be avoided.

If we need to buffer all SigComp messages before they are decompressed
then enough memory will need to be provided to meet the worst-case
message size (including the large messages that are sent over TCP).
This could be anything up to 64K.

However, if we can stream-decompress a SigComp message sent over TCP
then there is no need to buffer the entire message while it is being
decompressed. This means that we only need to provide a SigComp input
buffer large enough to cope with messages sent over UDP.

Another advantage of allowing SigComp messages to be stream-decompressed
is that the application may rely on the underlying transport to provide
security (e.g. TLS). In this case the application may wish to avoid the
overhead of using state identifiers and message delimiters (which are
unnecessary over TLS), opting instead to treat the entire TLS stream as
a single SigComp message. This approach saves at least 10 bytes per
application message when running over a secure transport.

> Actually, I believe all remnants of text about UDVMs staying active
> while waiting for external events should be removed from the document.
> (Ceterum censeo...)

If we allow stream decompression to take place then it's important to
allow the UDVM to request more input and pause until the input is
received. I can't see any way to avoid this.

> > Also, the definition of INPUT-BYTECODE is unclear about the
> > case of length == 0.
> 
> No, I believe it's perfectly clear.  As requested, you get zero bytes
> copied.  The operation succeeds (i.e., does not jump to @address), as
> no data beyond the input message was requested.
> 
> > I proposed to use length zero to indicate
> > "I want all the rest of the message". But that is moot if we
> > put message size in low memory.
> 
> Exactly.
> 
> The low memory approach also would allow the decompressor code to
> "plan" for the size of the input message before sucking it in.
> 
> > Then, we could clarify
> > zero length case by replacing fourth paragraph of section
> > 9.4.2 as follows:
> >
> > "If the instruction requests data that lies beyond the end of the
> > SigComp message or the requested data length equals zero, no data
> > is returned. Instead the UDVM moves program execution to the
> > address specified by the address operand."
> 
> That would be an unnecessary change (why put in a special case to fail
> on 0?).
> 
> (Generally, giving special meanings to special values of arguments for
> an operation generates trouble.  Making the change might mean that a
> decompressor must check a length of additional data it has computed
> for zero to avoid accidentally terminating when no additional data is
> needed.)
> 
> Gruesse, Carsten
> 
> PS.: Oh, the name INPUT-BYTECODE has become quite misleading now.
> How about INPUT-BYTES?
> (Or INPUT-OCTETS, if it must be :-)

Ok, let's make this change. Bytes and octets are both fine by me.

Regards,

Richard

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 17 Apr 2002 23:53:33 +0200

Richard,

I continue to believe the "instantaneous UDVM" model has significant
advantages.  In particular, a multi-session/compartment implementation
needs only one UDVM core, which therefore can be much larger than the
per-compartment/session buffer size.

On the other hand, the "persistent UDVM" model does have its merits,
as you say.  So I'm wondering: Can we accommodate both implementation
strategies?

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.  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.

Gruesse, Carsten

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