Subject: RE: [rohc] sigcomp-sip status

From: [email-masked]
Date: Fri, 14 Nov 2003 15:51:06 -0500

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

This is true in this example. However, the example has two assumptions:

a) The state is only the bytecode --> you have to upload it in the 
first message anyway.

b) Each message always triggers a message on the reverse direction
--> you'll know the truth when you send the second message, just in
time before you have to guess.

If *either* of the assumptions is untrue, we can no longer say 0KB SMS
costs nothing.

- For example, if assumption b) is untrue, we may have endpoint A
sends two messages (message 1 and 2) in a row before endpoint B returns
a response. Then, should A send bytecode state in message 2? For SigComp
over TCP, the bytecode in message 2 can be avoided if A knows the SMS
of B > 0.

- RE assumption a), A may want to upload dictionary state in the first 
message, which can be used to compressed the second or even subsequent 
messages it is going to send. This is particularly useful if the delay 
of the first message is not important (which is the case for REGISTER). 
However, without knowing whether B has SMS > 0, how can A decide whether
to upload the dictionary state and enjoy the reward latter? Unlike uploading
bytecode state in the first message (which you have to anyway), your
investment may or may not lead to any benefit depending on SMS of B.

BR,
Zhigang

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

---

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Mon, 17 Nov 2003 14:00:33 +0100

Hi,

I think allowing 0 byte SMS is reasonable. The extra cost of allowing this (if the true size is >0)if the optimistic approach is used is mostly zero.

Even if we expect and hope that all client and servers have a non zero SMS, I think we should still allow a zero byte SMS. It could perhaps be useful for temporarily overloaded proxies.

Best Regards
Jan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of West,
Mark
Sent: den 14 november 2003 16:45
To: Carsten Bormann
Cc: [email-masked]
Subject: Re: [rohc] sigcomp-sip status

Hi all,

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

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

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

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.

---

From: "West, Mark" <[email-masked]>
Date: Wed, 19 Nov 2003 15:24:02 -0000

Hi Zhigang,

Regarding a), I agree with you.  This is a counter-example that I had not
considered.  So, yes, if you don't know that the endpoint has SMS available,
you may decide not to upload user-specific dictionary state, and there may
well be a cost associated with that.

I'm not in a position to quantify that at the moment, but I accept the
point.

So far as b) is concerned, I don't think that this is (necessarily) just an
SMS issue (although it is a valid point).  If I send 2 messages to the
remote endpoint without receiving feedback, how do I know that the message
has successfully arrived; been correctly decompressed; and that the SIP
application has authorised the state creation?  If *any* of those are false,
then I can't make use of the state, even if remote SMS is available.  (Use
of TCP makes the first likely, but doesn't impact the others...)

Cheers,

Mark.

---

From: [email-masked]
Date: Wed, 19 Nov 2003 12:10:00 -0500

Hi Mark,

> So far as b) is concerned, I don't think that this is 
> (necessarily) just an SMS issue (although it is a valid point). 
> If I send 2 messages to the remote endpoint without receiving 
> feedback, how do I know that the message has successfully 
> arrived; been correctly decompressed; and that the SIP
> application has authorised the state creation?  If *any* of 
> those are false, then I can't make use of the state, even if 
> remote SMS is available.  (Use of TCP makes the first likely, 
> but doesn't impact the others...)

Very valid question. I've actually gone through it too, but
didn't spell it out to make my earlier email short. Now that 
you correctly pointed them out, my answer is (a bit 
surprisingly, or may be not): optimistic.

Here is a simple example to show the idea.

A              B
   m1 ------> 
   m2 ------>
   <------- m3

When A sends the second message m2, it can optimistically assume
m1 has survived the 3 conditions above, and use states uploaded 
in m1 to compress m2. In most cases (if the compressor is 
implemented correctly), the assumption should turn out true and 
thus A enjoys the benefit. In the rare cases where it doesn't, 
that means this is *already* a SigComp failure for *m1* which 
requires a recovery procedure for m1. (Here we link to the multiplexing
issue but I wouldn't deviate to that topic at this moment.) 
So, being optimistic does not add additional penalty.

Note that I've made one assumption in the above argument. That is,
sending m3 is conditioned on the receiving of m1 and m2, in order. 
This should be a reasonable assumption considering the nature of SIP
signaling. Otherwise, that means 

1) m3 depends only on one of {m1, m2}. In that case, why would A 
bother send both messages at all in the first place? We want to
reduce latency.

2) m3 depends on both {m1, m2}, but does not require them to
be received in order. I cannot recall a real-life SIP example of
this. But if it exists, there is indeed a penalty making m2
dependent on m1 *and* when a SigComp failure occurs on m1. Namely, 
A has to resend m2 (in addition to m1), which is not needed 
if A sent m1 and m2 independently in the first round. However,
I don't see this is a big concern for two reasons: a) SigComp 
failure should not be a frequent event, or we are in real trouble; 
b) the delay caused by resending m2 is second order to the delay 
caused by tear-down and reestablishment of same TCP connection, or
establishment of a new TCP connection which may require setting
up a new security association.

BR,
Zhigang