Subject: [rohc] some comments on sigcomp-05

From: [email-masked]
Date: Wed, 6 Mar 2002 19:46:32 -0600

Hi,

Good work by Richard. I see many cleanup and streamlining have
been done in this revision. Here are some comments:

1) Page 7, Figure 1. What is the arrow from Compressor (Decompressor)
1 to Compressor (Decompressor) 2 for? 

2) Same figure. It will not work well with encryption at application 
layer. One solution is to let the compressor dispatcher to pass a 
SigComp message back to the application so that it can encrypt
the compressed message and then send it out. On the receiving side,
let the application handle a SigComp message first and decrypt if
needed. Then, it can pass the SigComp message to decompressor 
dispatcher. The price for this approach is more interactions between
SigComp and application. Any thoughts?

3) Page 12. Should length = 111 be avoided (due to the escape
character 0xFF as Carsten mentioned)?

4) Section 7.1, first paragraph. To be more accurate, should it 
be 2-byte "unsigned" (i.e. non-negative) integer?

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.

BR,
Zhigang

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

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 7 Mar 2002 17:51:25 -0000

Hi,

Thanks for these comments on SigComp-05; I've added a few replies inline.

Regards,

Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 1:47 AM
> To: [email-masked]
> Subject: [rohc] some comments on sigcomp-05
> 
> 
> Hi,
> 

There isn't supposed to be an arrow between Compressor 1 and Compressor
2. I believe that the arrow you're referring to is the one between
Compressor 2 and the compressor dispatcher; due to space constraints on
the diagram the arrow unfortunately has to pass "underneath" Compressor 1.

I'll see if the diagram can be redrawn to make this clearer.

> SigComp and application. Any thoughts?

If encryption occurs on the application layer then this seems like the
most sensible approach. It's compatible with the current SigComp draft;
all that changes is that message transport happens to be provided by the
application rather than by TCP or UDP. Do we need to say anything in the
draft to take this possibility into account?

> character 0xFF as Carsten mentioned)?

I don't see any particular need to avoid length = 111, because we have
a byte stuffing scheme in place to deal with accidental occurrences of
0xFF within a compressed message. However compressors are free to avoid
length = 111 as an implementation choice if they don't want to bother
with the byte stuffing scheme.

> be 2-byte "unsigned" (i.e. non-negative) integer?

Yes - all integers in the SigComp draft are 2-byte unsigned values from
0 to 65535.

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

---

From: [email-masked]
Date: Thu, 7 Mar 2002 19:38:56 -0600

Hi Richard,

> I'll see if the diagram can be redrawn to make this clearer.

I see. Never mind. It was only my dumb brain that didn't parse it in 3D.
 
> draft to take this possibility into account?

If it is compatible, I suggest we put down some words in the draft. I
expect people will ask this question.
 
> with the byte stuffing scheme.

Right. A side comment for the same section, perhaps the length = 0 
case should be mentioned before the formula of n for easy reading.

> Yes - all integers in the SigComp draft are 2-byte unsigned 
> values from 0 to 65535.

How about those deltas in SWITCH, JUMP, COMPARE? Is there any
particular reason that we only allow the UDVM to jump forward?

> memory, or you can just copy the entire compressed message into the

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?

BR,
Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 11 Mar 2002 17:20:29 -0000

> particular reason that we only allow the UDVM to jump forward?

The UDVM always does arithmetic modulo 2^16, so negative numbers can be
supported by replacing -1 with 65535 and so on. This allows the UDVM to
jump backwards.

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

Regards,

Richard

---

From: [email-masked]
Date: Tue, 12 Mar 2002 16:09:06 -0600

I didn't expect my questions stirred up so much mud. :-)
Only wanted to get some clarifications on section 8.1.
Now, let me try to clean up the water again.

- Let's assume the SigComp header is standardized as in -05
I didn't think the alternative when I asked the questions.
(Richard, need to think more about your proposed new format,
will come back later). 

- Now, the question was what happens after a SigComp
message arrives at a SigComp endpoint. Below is what I get
after parsing the replies. It aims at clarity and may
not reflect all the possibilities.

1) The dispatcher parses the SigComp header. 
(Although it can be done by UDVM executing some preloaded 
UDVM code, let's ignore it for simplicity.)

2) Then it takes the following actions. Note this part 
in my view is NOT an implementation issue.

if ( header has state_id ) {
  /* below is a request to state handler. need to 
     update Figure 1 */
  state = retrieve_state(state_id); 
  if ( state == NULL ) /* e.g., state not found */
    stop;
  }
  /* for procedure below, see section 6.1 */
  copy state to UDVM byte buffer at state.state_start; 
  set UDVM program counter = state.state_instruction;
  start UDVM;
}
else { /* a stateless SigComp message */
  copy remaining message to UDVM buffer address 6;
  set UDVM program counter = 6;
  start UDVM;
}

Now, there are important differences between the
two cases I think section 8.1 should clarify:

1) For a stateless SigComp message, INPUT is not used 
because the whole message (code + compressed data) is 
already copied to UDVM byte buffer, right? (This was
my original question.)

2) Also, for the stateless case, the dispatcher must
have received the entire SigComp message before it
starts UDVM. That is not necessarily the case for 
a SigComp message with state reference.

BR,
Zhigang

---

From: [email-masked]
Date: Tue, 12 Mar 2002 18:31:32 -0600

(Sorry, more comments. The water is already muddier than I thought.)

- If everyone agrees with the understanding below, should
we remove the following text from section 4.2?

"The state identifier is then extracted from the SigComp message and
then executed as defined by the STATE-EXECUTE instruction of Chapter
9."

- Also, in section 6.1, propose to modify the paragraph after
the list of information for a state:

"The state_identifier must be supplied to retrieve an item of state
from the state handler. A state can be accessed using the UDVM
instructions STATE-REFERENCE and STATE-EXECUTE, or during the
parsing of a SigComp header (see section 4.2) without explicit
UDVM instructions. A state can be created using the END-MESSAGE
instruction."

- Section 6.1, list of state info. Propose to change "state_start" 
to "state_destination". It is then inline with STATE_REFERENCE and
avoids possible confusion ("state_start" has a different meaning
in STATE_REFERENCE).

BR,
Zhigang

> From: Liu Zhigang.C (NRC/Dallas) 
> Sent: March 12, 2002 4:09 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [rohc] some comments on sigcomp-05
> 
>

---

From: [email-masked]
Date: Wed, 13 Mar 2002 10:35:55 -0600

> In flexible mode, if a state reference is present, the rest 
> of the packet stays in input space. If no state reference 
> is present, all of the packet goes into the core.
> There is no end marker in this case.
> 
> It's not clear to me this makes sense.

My understanding is that for the latter case, the dispatcher
doesn't know the boundary between code and compressed data.
So, a safe way is to wait until get the whole stateless
SigComp packet. 

> Possible remedy:
> 1) provide a way to designate some of the packet for the 
> input space in the no-reference case of flexible mode.

See above. Not sure why we need this.

> 2) provide a way for the UDVM code to designate core space as 
> input space; also provide and end marker.

I assume by end marker you mean the end of current SigComp message.
Then, we need to escape the end marker again. Can we simply have
a length field in UDVM for this purpose? Also see below.

> Also, INPUT-BYTECODE is strange in that you have to know how 
> much is out there; you can't just say "give me what you have" except 
> through a binary search.

Yes, we need this. How about specifying that if length == 0, that
means "give be what you have" until the end of this message. Then
the callee returns the length.

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 13 Mar 2002 11:57:20 -0600

> > For example, algorithms that need more than 128 different 16-bit
> > quantities ...

Richard, a minor correction. It should be 64 16-bit quantities that
can be addressed with one byte (i.e. 01nnnnnn). 

> You could have the space all after the "cheap" space?

I agree with Carsten. To me, fixing X = 0x80 looks good enough.

But if that still doesn't satisfy Richard, below are some 
alternatives. 

Option 2 (1-byte X):

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

The SigComp message is copied to address (X*2)+6.
This gives [6, 516]. 

Option 3 (variable-length X):

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

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

The SigComp message is copied to address (X+6).

BR,
Zhigang