Subject: [rohc] sigcomp-sip status

From: [email-masked]
Date: Wed, 5 Nov 2003 18:20:38 -0500

Hi Folks,

The sigcomp-sip-00 has received few comments on the list (my thanks
to those who have kindly provided their feedbacks, particularly Abbie,
Jan, Pekka, and Robert). 

The comments so far focus on the following issues:
- Is 8K minimum DMS too large for SIP/SigComp?
- Is 2K minimum SMS necessary?
- Need for multiplexing SigComp messages and SIP messages on 
the same TCP connection?

Also, there has been little progress made on the compartment and state
management.

Since it seems to me that more discussions are needed on those issues, 
the sigcomp-sip-00 was not updated for the Minneapolis meeting. I plan
to update the I-D in December before it expires, hopefully with less
issues open. 

I would like to use this opportunity to encourage everyone to send your
comments on this list. 

BR,
Zhigang

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Nov 2003 16:17:32 +0100

Here is a braindump of a breakfast meeting Mark and I just had.
All great ideas are Mark's, all errors are mine...
Please excuse the terseness, this is mainly to preserve the many 
threads we had.

Gruesse, Carsten

2003-11-13 Mark West/cabo

Re sigcomp-sip draft:

8 K DMS is a no-brainer

2 K SMS means
-- can't compress to stateless proxies (i.e., "really stateless"
proxies can't advertise sigcomp)
0 K SMS means
-- can't establish state in initial message and rely on it
-- can still assume it's there -- need to wait for ACK to find out
for real
Mark will find a number for what 0 K SMS "costs".

Multiplexing:
Please use minimal UDVM programs (INPUT-BYTE, OUTPUT, JUMP) to carry
uncompressed messages in SigComp streams.  This is seven bytes plus a
four-byte SigComp header.

Compartment:
For INVITE/dialogs, the draft seems fine (but see below).
Note that, when a dialog ends, state may need to be kept around for
the odd retransmission (cf. TIME_WAIT).

Re: Maintaining state across dialogs: I propose to create a new SIP
header like:
SigComp-State-Promise: 1230402134098913284a729f 20h
(or absolute time, but relative seems more conservative --
implementations will need to compensate for RTTs and some time skew)
As with any state promise, this is just an optimization, so need not
be reliable.

REGISTER transactions?
There is no dialog to attach the compartment to.
BTW.  It would be nice to be able to keep user state (e.g., for a
re-register) for the duration of the registration.

What other pieces of state (in addition to dialog and registration)
are there that we may want to attach a compartment to?

The transaction/dialog dilemma could be solved by installing the
compartment for a transaction and later binding that to a dialog.
Some implementations may not even know the compartment at 100 Trying
time, so state installation may have to wait for 180 Ringing.
This would require the state to remain in limbo until SIP stack is
ready to acknowledge, which is what we are trying to minimize.

---

From: "West, Mark" <[email-masked]>
Date: Fri, 14 Nov 2003 15:44:54 +0000 (GMT Standard Time)

Hi all,

A bit of a follow-up, as promised/threatened...

... and I reserve the right to include errors of my own..! ;-)

> Mark will find a number for what 0 K SMS "costs".

I'm assuming the following simple sequence of 3 messages in a one-way
flow: REGISTER, INVITE, and ACK.  These have been run through a script
that I use for assessing compression efficiency.

For these results, the compression algorithm is EPIC (from the SigComp
users' guide), 'cause that's what I happen to have to hand...

The uncompressed message sizes are 322, 489 and 288 bytes, respectively.

The EPIC bytecode that I'm currently playing with is ~400 bytes.

So:

Per-message compression with static dictionary gives:
126, 201 & 131 bytes = 458 bytes in total (not including SigComp message
overhead or bytecode)
Bytecode adds 400 bytes to each message.  This, it can be seen, is not
terribly good value!  If bytecode were known to be available (advertised
by remote endpoint), some of this overhead could be avoided.

Dynamic compression (also with static dictionary) gives:
126, 157 & 23 bytes = 306 bytes total (not including overheads)
Bytecode adds 400 bytes to first message.

If you deferred the creation of state until receiving the advertisement of
2k SMS, then it would look (as expected), like:
126, 201 & 23 bytes = 350 bytes total (not including overheads)
Bytecode adds 400 bytes to the first 2 messages (excepting advertisements
or well-known bytecode)

As an observation, I can't see any reason why you would use the last case!
If it is *possible* that SMS will be available, and you know that it will
be at least 2k, then why not make an 'optimistic' state-creation request
on the first message?  If no SMS is advertised / no ack is received in a
response, then you have to use per-message / stateless compression.  If,
however, SMS is advertised / an ack is received, then everything should
proceed exactly as if you had known that there was 2k SMS all along..!

For the per-message / boot-strap case, we've played around a bit with
compact byte-code for simple compression such that the compressed message
+ bytecode is still smaller than the original message.

The 'best-case' though, would clearly be to have a 'well-known' algorithm
that could be used for the per-message / stateless scenario.

Hopefully that more or less answers the question..?

Cheers,

Mark.