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

From: "Price, Richard" <[email-masked]>
Date: Tue, 12 Mar 2002 16:45:54 -0000

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

Sorry for muddying the waters still further, but I think that we could divide
the above issue into two separate sub-issues:

1a) SigComp headers vs application-defined headers

1b) Parsing headers using handwritten code vs parsing headers using bytecode

Issue 1a is about whether we specify a mandatory header for all SigComp packets,
or whether we leave the choice of header as an application-defined parameter.

Issue 1b is about whether the header should be parsed using some specially
written code, or whether it should be parsed via some bytecode that is loaded
into the UDVM for every message.

I believe that issue 1a is the important issue; in fact the issue of whether
to decode the headers using a piece of bytecode or not doesn't affect
interoperability so it is just an implementation decision at the decompressor.

> Pre-loaded mode, of course, requires some pre-agreement that is outside the
> scope of the current work.

This is referring to issue 1a; if we leave the choice of header as one of the
application-defined parameters then this choice will need to be made in the
context of a particular signalling application.

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

I think that the above point is referring to issue 1b, but I'm not sure I
understand it because the choice of whether to decompress the header using
bytecode or not is just an implementation decision. So I don't see why
"flexible" mode is any more flexible than "pre-loaded" 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...)

I believe the above point is referring to issue 1b. As Carsten says, once we've
defined the SigComp header it's just an implementation decision whether to
decode it using UDVM bytecode or using C.

> 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.
> 
> > 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"?
> 
> 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.]

From an architectural perspective the entity which parses the SigComp
header is the dispatcher. From an implementation perspective you can
provide this functionality using UDVM bytecode if you like (although
this wouldn't save much implementation effort because the current SigComp
header is so trivial).

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

The above text is too restrictive, so I'd prefer to replace it with the
following:

     If the length value is set to 0 then no state is accessed; instead
     the entire SigComp message (excluding the 3-byte SigComp header) is copied
     into the UDVM memory beginning at Address X, and then executed starting
     from Address X.

The value of X could be transmitted as part of the SigComp header when the
length value is set to 0, for example:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1 | Length=0  |
+---+---+---+---+---+---+---+---+
|           MSBs of X           |
+---+---+---+---+---+---+---+---+
|           LSBs of X           |
+---+---+---+---+---+---+---+---+

This would save having to put an explicit JUMP instruction at the beginning
of all downloaded UDVM bytecode.

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 13 Mar 2002 14:43:53 +0100

A JUMP may not be necessary in many cases, in which case this would cost two
bytes more than necessary.
If a JUMP is necessary, it typically costs the same two bytes (unless the
code is large).
So I'm not sure that's a win.

The only reason I know to load code at a different position than 6 is that
%-style operands make it cheaper to address 16-bit quantities in low memory
(0..128).
Couldn't we fix X at, say, 0x80?

Gruesse, Carsten

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