Subject: RE: [rohc] sigcomp issue lejo-8

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

> "Price, Richard" <[email-masked]> writes:
> 
> > The UDVM memory does need to be around until the session ID 
> is returned
> > by the application. The state item that the UDVM wants to 
> create needs to
> > be stored somewhere, and for simple algorithms (certainly 
> all that I've
> > written so far) the state item is around 95% of the total 
> UDVM memory.

[Carsten wrote:]
 
> My (possibly slightly more abstract) mental model is that the output
> message plus the parameters of the END-MESSAGE stay around while the
> app is interrogated.  Not the UDVM.
> 
> Now, as an optimization, you may want to keep the UDVM core around to
> avoid the copying, but I would not want that optimization in the
> model.  In the model, the UDVM dies with END-MESSAGE.

I agree with Carsten. Call me a purist if you like. :-) 

Re the copying, you only save it if the message is rejected by app.
For an accepted message, you have to copy those stuff (e.g. states)
at least once from UDVM bytebuffer to outside UDVM. Then, if you
can avoid moving them around afterwards (easy for states, they
can be anywhere in state handler as long as you hold the pointers),
there is no additional cost even in the "pure" model.

Zhigang

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

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 16 Apr 2002 17:54:47 +0100

> > app is interrogated.  Not the UDVM.

Hi,

I have a somewhat different mental model of SigComp. In my own model I
believe that each piece of information required by SigComp should have a
logical entity that stores this information. I think that this is nice
for keeping the architecture "pure", and also useful when considering the
security implications of SigComp.

The newly requested state item shouldn't be kept by the decompressor
dispatcher, because the responsibility of this entity is simply to provide
an interface between the UDVM (which is protocol-independent) and the
particular application and transport that are currently in use.

Also the state item shouldn't be given to the state handler until the
session ID is available because (in my opinion) the state handler only
cares about sessions and not messages. In particular it only stores per-
session data and not per-message data.

Rather than invent a completely new logical entity to store the item of
state before it is created, I prefer to think of the UDVM as remaining
open until the session ID has been provided.

> I agree with Carsten. Call me a purist if you like. :-) 

As a pure mathematician, I'll always choose the "purest" mental model over
the easiest model to implement. The fact that my own mental picture of
SigComp seems to coincide with how it would actually be implemented is
something of a minor miracle - as Mark West will no doubt confirm this
has never happened before and will almost certainly never happen again...

> there is no additional cost even in the "pure" model.

From an implementation perspective the mental model we each choose to
adopt isn't important. I prefer the UDVM to hold a pending state
creation request because I believe that it is "purer" than giving the
state to the state handler (or storing it in limbo) before it has been
accepted by the application.

Regards,

Richard

---

From: [email-masked]
Date: Tue, 16 Apr 2002 19:25:48 -0500

(All right, it is clearly my mistake to mention the word "pure". I
should have known that. )

Going back to the issue, can we agree on the following?

a) optimization is not the reason for choosing one over the other. 

b) the reason we have UDVM is to support different decompression 
algorithms without negotiation. Nothing more than that. Its minimal
job is to decompress and interpret state creation requests. Whether 
one wants to put more functions to UDVM is an implementation issue. 
Therefore, the text should not dictate either way.

(To me, keeping UDVM lifetime shorter simplifies interfaces. But
others may want to implement differently.  )

BR,
Zhigang

> -----Original Message-----
> From: ext Price, Richard [mailto:[email-masked]]
> Sent: April 16, 2002 11:55 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [rohc] sigcomp issue lejo-8
> 
>

---

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

Hi,

I believe that I now understand Carsten's original objection to the
way the UDVM interfaces with its environment. In Carsten's model the
receiving endpoint buffers a complete SigComp message, invokes the
UDVM to decompress the message, and then closes the UDVM as soon as
the message is decompressed. There is no need for the UDVM to pause
and wait for more data to become available.

However, the current version of the UDVM has a more complex interface
with its environment in order to efficiently support stream-based
transports such as TCP and TLS.

As we discussed on the mailing list a while back, an application may
choose to provide security on the transport layer (e.g. by invoking
SigComp over TLS). In this case there is no need to use the SigComp
state identifiers or message delimiters at all - we don't weaken
application security by avoiding them (because the session IDs are
provided by TLS, independently of the contents of each application
message).

The benefit of omitting the state identifiers and message delimiters
is a compression boost of at least 10 bytes per application message.
The cost is that the UDVM needs to run for the entire duration of a
TLS session - in particular it must have the ability to request new
data from the stream and then pause until the data has arrived.

Another benefit of the pause-and-wait model is that we cut the memory
requirements of the UDVM - there is no need to buffer an entire
SigComp message over a stream-based transport. This is particularly
important for SIP, which uses TCP specifically to carry large messages
that would cause fragmentation to occur over UDP.

> others may want to implement differently.  )

Yes - the difference between the two models is the maximum duration
of the UDVM lifetime. In the buffer-a-whole-message model the UDVM
lifetime is very short, which simplifies the interfaces to the
environment. In the pause-and-wait model the UDVM lifetime is as
long as can be permitted by the application security mechanism - if
TLS is used the UDVM may persist for the entire duration of a TLS
session. This requires a more complex interface to the environment,
but in return it improves the overall compression ratio and reduces
the working memory requirements.

So, which is the better model to adopt? Although we could easily
avoid the pause-and-wait nature of the final state creation request,
I see little benefit in doing so unless we change the pause-and-wait
nature of the INPUT instructions as well. Does anyone see a benefit
in making this change given the advantages and drawbacks outlined
above (plus any others that I've missed)?

Regards,

Richard