Subject: [rohc] sigcomp issue list

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 15 Mar 2002 09:55:50 +0100

Sigcompers,

here is my current issues list for discussion.
I have given the issues tags that start with my name (not because they are
my issues, but because others may want to add to the list independently).
If you want to discuss an issue on the list, please use the tag as the
subject, e.g.

   Subject: sigcomp issue cabo-13

If possible, please separate the threads between issues.
This will also facilitate declaring closure on specific issues at some
point.
(Some time we'll have WG tools to manage all this automatically...)

Gruesse, Carsten

* UDVM instruction set issues

cabo-13) missing instructions:
SHIFT (left, right, sign-extending right?)
MODULO

cabo-12) byte_copy_right should point to first byte after buffer, not last
byte of buffer

cabo-11) INPUT-BYTECODE strangeness (can't find out how much is there)

cabo-10) NBO vs. INPUT-HUFFMAN/-FIXED, need to document this more precisely

cabo-9) (the whole NBO instruction approach -- shouldn't there be
separate LSB and MSB instructions?)

* state management

cabo-8) STATE-FREE -- is it needed, can it be made secure?

cabo-7) STATE-REFERENCE vs. STATE-EXECUTE -- can these (should these) be
unified?

cabo-1) what is the right hash for state?
(MD5 vs. SHA-1, any algorithm additions?

cabo-2) We need to decide how to do the state identifier truncation --
it should be possible to use different state identifier sizes to
reference the same state (substring match).
I think the size should be an aspect of the reference, not of the state.
So you do a prefix-match.  (Implementation-alert:
As we have a minimum reference size of 6, this could be your hash in the
implementation; the rest is just check/chaining.)
Similarly, END-MESSAGE should not have a hash-length operand.

cabo-14) We need to put all the information in a piece of state into the
hash.
We need to define more precisely how that is computed from this information.

* external interface

cabo-6) how to divide a stateless message into code and input
(or, how to
-- input stuff from core
-- find out the length of the input message)

cabo-5) in a stateless message, load code where, start where?
(6 certainly sounds wrong, very wrong)
(do we need, e.g., two more bytes in the message?
can this be coded efficiently, e.g. as a log2 from 3 to 15?)

cabo-15) How many values should there be for UDVM parameters?
(e.g., fix six or seven values for UDVM size and use three bits in an
announcement.)
Memory size can be expressed in 3 bits:
1, 2, 4, 8, 16, 32, 64 K(1024)Bytes
(1 is way low, but 3 bits allow you to say this)
If this is too coarse, add a "and-a-half bit":
1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64
Similar mickey-mouse floating point can be used for cycles-per-bit (3 bits
give you 1 to 128) and cycles-per-message (5 bits give you 1 to 2 billion).

----------------------------------------------------------------------------
-
Issues that do not necessarily influence draft-ietf-rohc-sigcomp:

* What I believe to be non-issues

efficiency of SWITCH

* Assembly language fixes

no default symbols (need to talk explicitly about byte_copy_start,
byte_copy_end, stack_location, reserved_end, total_length explicitly)

assembly language method for indication of program start?

align n
:sym val1 op val2  (:res_end here - 1)

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

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Mon, 18 Mar 2002 20:30:18 +0100

Sigcompers,

I have compile some information from the various issues posting that have
been on the mailing list.
I hope this is a useful recap for people preparing for tomorrow's meeting.
I'm not claiming any of this is authoritative.
If you reply (please do), please change the subject to "sigcomp issue
xxx-nn", where xxx-nn is the issue number.

Gruesse, Carsten

lejo-1) In section 3.1 (page 9), it is written that SigComp usage is
indicated
        by using different port numbers. Did we not agree that this is one
        option, but not necessary the way it is done. SigComp messages are
now
        self-identifiable.

[[
I believe the consensus is that Sigcomp should be open to a number of
ways to do the multiplexing; sigcomp itself contributes identifiable
messages, but using port numbers or some other scheme definitely
remains possible.
We may have to mention at some point that it is unlikely there will be
compressed ports reserved for each signalling protocol likely to use
sigcomp.
]]

lejo-2) Use of static dictionaries, how is that envisioned? First of all, I
        assume it should be mentioned and explained, e.g. when per-message
        compression is defined. Further, 6.3.3 may be interpreted as if
static
        dictionary usage is about announcing certain pre-defined states. Is
        that a good approach? Should one not define a static dictionary for
        each SigComp application, e.g. SIP, that must be used as a minimum?

[[
The sense of the IETF-3GPP ad-hoc on this was, yes, we should define
one such static dictionary for SIP.  It is static in that it really
does not change, even if further extensions get added to SIP.
]]

lejo-3) We must standardize how SigComp is used for e.g. SIP (at least).
This
        includes default values for all application parameters, the
mechanism
        used to separate SigComp/SIP from normal SIP messages, and maybe a
        mandatory static dictionary.

[[
See lejo-2 above.
For the parameters, let's see how they distill (cabo-15); once this is
done, it may be almost obvious what to use for SIP.
The whole thing should be specified in an annex to sigcomp, to clearly
identify it as something that is separate from sigcomp itself, or,
alternatively, as a separate draft.
]]

lejo-4) In terminology and section 6.1, second paragraph, dynamic
compression
        is mentioned as an important mechanism for improved compression
        efficiency, but not at all explained how to implement. We all know
        why, but for a reader this is strange. Should we clearly refer to
        the document that explains how to implement this and other useful
        enhancements?

[[
This is a document dependendy question.
Discuss.
]]

lejo-5) In section 3.2, "Initial State": What does the last sentence mean?
        "Each item of initial state can be made mandatory for every instance
        of the application, or it can be optional." First, "each" indicates
        a limited set, should it be "any"? Further, "can be made mandatory",
        by who? In which context, for e.g. all SigComp SIP usage, or?

[[
ed.
]]

lejo-6) State deletion, discussed in 6.1 and 6.2. First, I get a feeling
that
        something is missing after the first (continued) sentence on page
17.
        An obvious question from a reader is "how can the state handler
        determine that?", which is not answered. Further, when section 6.2
        describes how to save and delete state, this becomes confusing.
        * Why should a decompressor save state? Answer: Dynamic compression.
        * Is it possible for a compressor to know what has been saved by
          the decompressor? Answer: Yes, if acks are used.
        * Can a decompressor decide what to delete if states has been
          acknowledged for use by the compressor? Answer: No, then the
          decompressor must know that the state will not be used again by
          the compressor.

lejo-7) In section 5.1, some things are confusing.
        * 2) is not sufficient for dynamic compression usage, since the
          compressor do not know what a decompressor saves. Not everything
          is saved, right?
        * 3) talks about pre-defined, who defines that? Further, available
          pre-defined state must then also be announced by the decompressor.
          These pre-defined states require a state-identifier space to be
          defined for registration of state-identifiers.

lejo-8) In section 6.1, third paragraph, the application->state handler
        interface is explained, but unclear. If an application does not
        validate a state, nothing is provided. Should it not be clearer
        if the handler (for each state) is provided with the following
        from the application: [Identity, State-ID], where Identity
        may have an error value indicating an invalid (and useless) State.

lejo-9) The IANA section must be clearer, if we want a SigComp pre-defined
        state-identifier space to be set up for reservation of values to
        use in state-announcements.

[[
I believe there is now consensus to use hashes only, with a minimum
identifier size of six bytes.  This obviates a registry.
]]

lejo-10) Extended operations: To support e.g. explicit acks is an
         implementation issue. However, as SigComp is now defined, this
         is about having it implemented at both "sides" to get the
         functionality. What I mean is that to use dynamic compression
         between compressor1 and decompressor2, compressor2 must provide
         acks for decompressor2 states. Is this a nice solution? Would it
         not be possible to define SigComp so that compressor1 could
         implement this by using the right UDVM instructions to force
         "state acks" for saved state from decompressor2? As it is now, both
         sides must explicitly implement this to get any benefits, and that
         is not a nice way of having an implementation option.

lejo-11) If we define an IANA number space according to lejo-9 above,
         should we define identifiers for the "extended operations"
         mechanisms, to be able to announce support of those?

[[
see lejo-9
]]

Richard 2002-03-06:

rp-1 *   Is the SigComp announcement information secure? If so, we'll need
some
    text to prove it!

[[
Need text about endpoint identifiers being established by the
application.
]]

rp-2 *   Should the hash be MD5 or SHA-1?

[[
Interesting discussion.
One idea was to allow both.
]]

rp-3 *   Are more CRCs needed (we currently only have a 2-byte CRC)?

rp-4 *   Can we agree on fixed values for any of the parameters in the
    announcement information (this would save having to announce them)?

[[
== cabo-15
]]

rp-5 *   Should we avoid using opcode 0 (makes it marginally easier to
disassemble
    UDVM bytecode)?

[[
In any case, 0 would then cause a DECOMPRESSION-FAILURE, so we might
as well define 0 to have this meaning.
The initial reason to ask for this might go away with the cabo-6 resolution.
]]

rp-6 *   Do we need to bit-quash the announcement fields?

[[
Yes, but first decide on cabo-15
]]

rp-7 *   Should the state identifier hash be calculated over the entire
state
    (including state_start, state_length etc.) rather than just over the
    state_value?

[[
I don't know about state_length, as this is implicit, but we have to
avoid collisions between the same pieces of state being located at
different start/end points.
== cabo-14
]]

rp-8 *   Should each message be able to create more than 1 item of state?

[[
Yes, but how to do this without increasing overhead?
New instruction STATE-CREATE?
]]

Zhigang:

zliu-1: (this is related to cabo-15) what are the default
minimal values for the application-defined parameters, at
least for SIP? Perhaps they can go into a separate draft,
but are needed to run SigComp to compress SIP.

[[
== cabo-15 and lejo-3
]]

zliu-2: will negotiation of whether to use SigComp be specified
in IETF or outside (e.g. 3GPP)?

[[
Not in sigcomp itself.
]]

cabo:

[[
Let's do them -- very low cost.
]]

[[
Sufficient discussion -> yes, make it so.
Make sure the modulo-16 properties get explained, so, if
byte_copy_right is 0x0000, the circular buffer extends right to 0xFFFF
inclusive.
]]

[[
Could use Richard's inefficient solution.
]]

[[
Separately discuss consumption bit order from reconstruction bit
order; spell out that the latter may differ between bits obtained from
the same input byte and those from a different input byte.
]]

[[
Depends.  Changing the consumption bit order should simply discard
half-used bytes.  If we have more than two kinds of bit order, having
an instruction to change a setting suddenly seems more reasonable again.
]]

* state management

[[
Hinges on endpoint identity concept.
Need to explain the need for reference counting in an implementation.
]]

[[
relates to the issue cabo-14 and to the general question "what
is/should be in a state
]]

[[
== rp-2
]]

[[
After some more discussion, it becomes clear that there is a benefit
in allowing the creator of state to specify a *minimum* reference
length.  This gives the creator some security in that only references
that use this minimum length will work.  So the END-MESSAGE parameter
would remain (change its name though).  All identifiers stored with
state will be 16 bytes, though, fully populated; this allows
longer references than the minimum reference length, which give the
referencer some security that they will get the right state.
]]

[[
see cabo-7 and rp-7
]]

* external interface

[[
A mailing list discussion resulted in:
a stateless message will have a two-byte prefix, four bits of which
indicate the *end* of the code space in the UDVM in 2^n style, and 12
bytes of which can be used to specify the length of the code.
The code then will be loaded to and be started at 2^n-length.
The rest of the message is provided as input for INPUT-* instructions.
]]

[[
see cabo-6
]]

[[
Proposal:
There should be a single setting for "buffer size", which controls all
three existing parameters compressed-message-size, UDVM-memory-size,
decompressed-message-size.
Reason: Only memory-starved implementations need to restrict this, and
they will have to save on all three of these buffers.  Typically, they
roughly need to be the same size.
Values: 2K, 4K, 8K, 16K, 32K, 64K.  Three bits of encoding.

cycles-per-message is renamed into overhead-bits-per-message. This
number is set at 1000 for UDVM version 0; it indicates the number of
cycles-per-bit units that are added to the cycles-per-bit of the input
message.

cycles-per-bit is encoded as a 2^n.  Default is 4.  A reasonable
maximum might be 128, resulting in the need for three encoding bits in
the announcement.
]]

efficiency of SWITCH

align n