Subject: RE: [rohc] some comments on sigcomp-05

From: [email-masked]
Date: Mon, 11 Mar 2002 12:30:35 -0600

> > > > 5) Section 8.1. After a UDVM is instantiated, should it be
> > > > initialized so that it can bootstrap by starting with INPUT 
> > > > one byte from decompressor dispatcher to parse the fist byte
> > > > of a SigComp message? I remember vaguely this was mentioned
> > > > somewhere in sigcomp-04 but I cannot find it in -05.
> > > 
> > > The UDVM is now initialised using the SigComp header of Section
> > > 4.2. The header offers two choices: you can send a state 
> identifier to
> > > retrieve a piece of stored UDVM bytecode and copy it into the UDVM
> > > memory, or you can just copy the entire compressed message into the
> > > UDVM memory.
> > 
> > You mean the decompressor dispatcher does all of the above? But 
> > according to text in same section, the "compressed data is not
> > provided to the UDVM by default" and the UDVM uses INPUT instruction
> > to request it. A contradiction?
> 
> When the SigComp header contains a state identifier the UDVM does not
> receive any compressed data by default. Instead it is loaded 
> with an item
> of state information, which (presumably) contains at least one INPUT
> instruction for retrieving the remainder of the compressed message.

I'm still confused. Rephrase my questions:

1) Who parses the SigComp header? The decompressor dispatcher or the
UDVM? If it's UDVM, does it follow some UDVM code initialized, or it
has the parsing logic "built-in"?

2) After parsing the header and there is no state ID, what then?
I guess it would be to copy the remaining SigComp message into UDVM 
memory. But by who? Also, the UDVM needs to know the position of
first bytecode to execute. I cannot find it in well-known variables
and application defined parameters. Should we specify it as part
of well-known variables (e.g. first_instruction) for the no-state-id
case?

BR,
Zhigang

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

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Mon, 11 Mar 2002 23:41:17 +0100

> I'm still confused.

Zhigang,

I think some confusion here stems from the fact that there actually are two
major distinctions that have been discussed:

1) flexible vs. pre-loaded mode

Some people are envisioning a mode of usage for the UDVM where the UDVM
header is never used, but instead the application *always* loads some code
into the UDVM that reads the packets.
I.e., the sigcomp message format is never used.
I call that pre-loaded mode, in contrast to the flexible mode defined
in -05.

Pre-loaded mode, of course, requires some pre-agreement that is outside the
scope of the current work.
I wouldn't recommend using pre-loaded mode for general signaling
compression, as it removes some flexibility, but there may be applications
for it, e.g. it might be nice as an IPCOMP mode.

(Of course, flexible mode can be implemented in UDVM code, so flexible mode
can be implemented by a UDVM implementation that only supports pre-loaded
mode...)

2) in flexible mode, state-referencing vs. stateless packets

In flexible mode, we have a defined header for the sigcomp packets.
The header indicates whether state is referenced that is loaded upon arrival
of the packet, which state then can parse the rest of the packet, or whether
the packet is entirely self-contained (no state referenced before the code
in the packet is run).  Only in the latter case, we need conventions for
initializing the UDVM with the contents of the packet.

> has the parsing logic "built-in"?

In flexible mode, it's the dispatcher (although a pre-loaded mode only
implementation might want to pre-load flexible mode code).
[Uuuh, what a sentence. It's getting late here.]

> of well-known variables (e.g. first_instruction) for the no-state-id

-05 specifies (section 4.2):

   If the length value is set to 0 then no state is accessed; instead
   the entire SigComp message is copied into the UDVM memory beginning
   at Address 6, and then executed starting from Address 6.

I'm not sure it's optimal to use 6 in both instances here, we certainly can
discuss that.

Gruesse, Carsten