Subject: RE: [rohc] sigcomp issue list

From: [email-masked]
Date: Fri, 15 Mar 2002 11:19:00 -0600

Carsten,

Can I add two issues from the perspective of users of SigComp? 
I may have missed emails that already closed them.

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

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

Zhigang

> -----Original Message-----
> From: ext Dr. Carsten Bormann [mailto:[email-masked]]
> Sent: March 15, 2002 2:56 AM
> To: [email-masked]
> Subject: [rohc] sigcomp issue list
> 
> 
> 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
> 

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

---

From: [email-masked]
Date: Fri, 15 Mar 2002 11:54:41 -0600

Sorry, need to rephrase zliu-1 (typos and poor grammar):

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.

Zhigang

> From: Liu Zhigang.C (NRC/Dallas) 
> Sent: March 15, 2002 11:19 AM
> To: 'ext Dr. Carsten Bormann'; [email-masked]
> Subject: RE: [rohc] sigcomp issue list
> 
> 
> Carsten,
>

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Sat, 16 Mar 2002 14:13:59 +0100

Zhigang,

> but are needed to run SigComp to compress SIP.

Yes, we need to standardize how the default usage of SigComp
for SIP works, and the right place to put this (short) 
material might probably be in the SigComp document (one
separate section in the end).
 
> in IETF or outside (e.g. 3GPP)?

SigComp messages are now self-identifiable, that should be
enough for us, right?

/L-E

---

From: [email-masked]
Date: Sat, 16 Mar 2002 23:41:55 -0600

> SigComp messages are now self-identifiable, that should be

No. The issue is how does endpoint 1 even know endpoint 2 supports
SigComp in the first place?

BR,
Zhigang

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Sun, 17 Mar 2002 16:03:48 +0100

> SigComp in the first place?

For the 3GPP case, this should not be a problem since support for SigComp
will be mandated in both Proxy and UE. Identification of compressed packets
should thus be enough there. However, you are right that for the general
case there should be explicit mechanisms for this, as has also been
proposed, but that is going beyond the charter of ROHC alone.

This was previously discussed in:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00053.html
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00069.html
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00088.html

The intension with the compressed identifier is to make SigComp packets
recognizable, which is something we (in ROHC) can define ourselves and have
in the SigComp standard. It would be enough for now without preventing explicit
multiplexing mechanisms to be further defined, apart from SigComp.

Rgds,
/L-E

---

From: [email-masked]
Date: Sun, 17 Mar 2002 16:43:38 -0600

Lars-Erik,

I was asking about negotiation. You were talking about multiplexing.
They are two separate issues. Let's stay with the original question.

> will be mandated in both Proxy and UE.

Are you sure? I heard it is optional, but I may be wrong. 

> you are right that for the general

So, you're saying it won't be done in ROHC. Will it be done in other
WG in IETF (e.g. for SIP in SIP WG)? I feel this is better to be done
in IETF for e2e operability. But this will be less urgent if SigComp
is mandatory in 3GPP as you said.

BR,
Zhigang

> From: ext Lars-Erik Jonsson (EPL)
> [mailto:[email-masked]]
> Sent: March 17, 2002 9:04 AM
> To: [email-masked]

Rgds,
/L-E