Subject: [seamoby] Compression startup behavior

From: Mikael Degermark <[email-masked]>
Date: Sat, 24 Mar 2001 12:50:23 -0700 (MST)

To: [email-masked], [email-masked], [email-masked]

Hi Rajeev, 

You are right that the text is a reasonable first approximation, 
but as it portrayed the situation to be somewhat worse than it
really is, I felt that it was prudent to help make it more accurate.

The reality of ROHC context establishment, according to the ROHC
spec, is as follows:

1) All new contexts MUST start out in U-mode. Thus, it is the U-mode
   rules that govern compressor behavior until feedback reaches the
   compressor. The ROHC spec says that the U-mode startup behavior
   is to send a small number of IR packets, followed by periodic
   repetition of IR packets. The period should be rather long. 
   The compressor MAY use an exponential backoff until the 
   periodic interval is reached. 

   The small number I picked, three, will be different for different
   implementations but is not completely unrealistic. It has nothing
   to do with whether an ack is received or not. This is U-mode.

2) Swithcing to R-mode or O-mode cannot happen until feedback 
   indicating that a mode switch is desired is received from the 
   decompressor. Thus, it can happen at the earliest after a
   roundtrip time, and so can happen after 6-10 packets with a 
   roundtrip of 120-200 milliseconds.

3) The decompressor will move to full-context state as soon as it
   receives any IR packet with complete information. 
   The default values for slopes, etc, have been picked such that
   telephony streams only need one such packet before minimal headers can 
   be decompressed correctly. If the actual values deviate from what is
   expected for telephony, two IR packets need to be received 
   before minimal headers can be decompressed correctly. 

4) It *is* possible for the compressor to go to SO state after
   sending only IR packets. Transition to SO state is governed by 
   whether a pattern has been established, and also IR packets can
   establish patterns as they can contain the dynamic part of the
   header. 

OK?

I think that the problems with the text was that it assumed that
the compressor started out in R-mode, and that IR packets could not
establish a pattern. Under those conditions, the text is correct.
Those are not the actual conditions, however.

Cheers, 

Micke

---

From: [email-masked]
Date: Sun, 25 Mar 2001 12:44:32 -0600

Hello Mikael,

thanks for the clarification. I have more questions below.

I get the feeling that if my text portrayed the compression initialization
behavior to be worse than the actual, your input seems to be inclining
towards the opposite! 

Regards,

-Rajeev

>    is to send a small number of IR packets, followed by periodic
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well, the rohc draft mentions "several packets". 

Section 5.3.1.1.1
"The compressor normally obtains its confidence about decompressor
   status by sending several packets with the same information according
   to the lower compression state. If the decompressor receives any of
   these packets, it will be in sync with the compressor. The number of
   consecutive packets to send for confidence is not defined in this
   document. "

The basic problem is: how does the compressor know that the decompressor has
the Full Context ? If the answer is it need not, then you take a chance
after sending "pre-defined" number of packets, and roll-back with costly
operations when the decompressor does not have the Full Context (in the
U-mode you simply repeat the IR packets). If the answer requires that it has
to, then you wait for an ACK. 

>    implementations but is not completely unrealistic. 
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In other words, 3 is the best case with rather low probability of being
feasible in practice  ? You say here clearly that the initial number of IR
packets is implementation-dependent. Is there any consensus in rohc that
sending 3 IR packets is sufficient, especially in those links with high
error probabilities ? If yes, could you point me to any relevant document ? 

>It has nothing to do with whether an ack is received or not. This is
U-mode.
>    roundtrip of 120-200 milliseconds.

An observation I have with your text here is that you don't mention when the
compressor transitions to FO/SO state after starting out in IR state in
U-mode. Could you please clarify ?

>    be decompressed correctly. 

Could you explain to me how you can establish a slope with one packet ?

>If the actual values deviate 
> from what is

Again, the problem is how does the compressor know that decompressor has the
required state ? In the rohc draft, the same is stated as "the compressor
must have sufficient confidence" or something alike.. I guess two approaches
discussed in rohc draft are

1. send several packets, transition to higher compression state, and repeat
IR packets (U-mode), or revert back to lower compression state when
compressor determines (through a NACK e.g.) that decompressor does not have
the required state (O-mode). 

2. compressor uses an ACK to gain the required confidence (R-mode). 

In both cases above, it appears that in order for the compressor to gain the
required confidence, several packets are needed, especially in a link with
higher error probabilities.

>    establish patterns as they can contain the dynamic part of the

Exactly the same point again: How does the compressor know that the IR
packets it transmitted definitively or almost certainly established the Full
Context at the decompressor ? 

I guess it is possible. I can also imagine when it is also *not* possible,
especially when you are operating under high error links such as those found
in cellular. 

> OK?

Well somewhat.. I still have unanswered points above. Also, could you answer
the questions I had in my previous e-mail as well ?
 
> Those are not the actual conditions, however.

Thanks for the clarification regarding every mode starting out in U-mode. 
Could you care to explain _what_ are the actual conditions (other than every
rohc implementation starting out in U-mode) ?

Do you agree with items 2 and 3 in my summary in the previous e-mail ? Here
they are again!

2. Context initialization is expensive in unreliable links. Since this has
to
be done for _each_ packet stream individually, it gets worse with multiple
packets streams (such as with multimedia streams). It further exacerbates
with
frequent handovers.

3. Context relocation, typically performed over high-speed wireline links,
provides a feasible alternative to context re-establishment during
handovers.
It provides a mechanism to _seamlessly_ continue _all_ the compression
contexts belonging to the MN, along with performance benefits. I think this
is
just right for seamoby to tackle!

> Cheers, 
> 
> Micke
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 29 Mar 2001 16:26:23 +0200

Some comments below...

> feasible in practice  ?

No, the best case would be 1, while 3 probably would be a good candidate for realistic conditions and VERY FEASIBLE IN PRACTICE. If the systems are providing acceptable service quality, higher numbers should not be needed. 

> especially when you are operating under high error links such 

We are talking about consecutive losses, and for such losses 3 is a high number. Further, the compressor does not need to know. It can be optimistic, as ROHC states. There is a trade-off between efficiency and robustness, and with a sufficiently high number (3 could be that number), optimal efficiency can be achieved without affecting the performance experienced by users.

We could probably argue about this for months (see ROHC mailing list from April 2000), so I will try not to continue this discussion. I guess that context transfer is a mechanism that will be developed and some people will think it is usable while others will not. That is something we must accept...

Rgds,
/L-E

---

From: [email-masked]
Date: Thu, 29 Mar 2001 11:34:41 -0600

> No, the best case would be 1, 

... if there are no transmission errors and the compressor knows
this.

> while 3 probably would be a 
> good candidate for realistic conditions and VERY FEASIBLE IN 
> PRACTICE. If the systems are providing acceptable service 
> quality, higher numbers should not be needed. 

3 may or may not work. It depends. In cellular, "acceptable 
service quality" means different thing at different time and 
location (of the mobile node). When you are driving in your car 
in a traffic jam at 5pm, a higher packet loss rate is acceptable 
(to the operator, not you). The very reason that a handover
occurs is due to poor radio conditions at the edge of a cell,
which means you are also at the edge of the new cell after
handover, which means the condition of the new channel probably
will not be very good either. Those factors have to be 
considered.

> We could probably argue about this for months (see ROHC 
> mailing list from April 2000), so I will try not to continue 
> this discussion. 

Oops, I just did. 

> I guess that context transfer is a mechanism 
> that will be developed (snip)

Good, at least we agree on one thing.

Br,
Zhigang

---

From: [email-masked]
Date: Thu, 29 Mar 2001 13:40:21 -0600

> -----Original Message-----
> From: Liu Zhigang (NRC/Dallas) 
> Sent: Thursday, March 29, 2001 9:35 AM
> To: 'ext Lars-Erik Jonsson (EPL)'; Koodli Rajeev (NRC/MtView);
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [rohc] Compression startup behavior
> 
> 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a good starting position.

Regards,

-Rajeev

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Fri, 30 Mar 2001 09:23:13 +0200

Sorry that I forgot to say "unfortunately" in the beginning of the sentence below...

Anyway, I do not care if someone wants to do context transfer as part of the handover procedures used for certain environments. Personally, I think it is overkill and makes things more complicated, but that is not up to me to judge. However, it is not a header compression issue.

/L-E

---

From: [email-masked]
Date: Fri, 30 Mar 2001 10:14:49 -0600

> However, it is not a header compression issue.
> 
> /L-E

Sorry, I still don't get it after the statement has been 
repeated many times (both this and last year). Do you mean 
that the logic (e.g. not sending IR packets to reestablish
context over the air after receiving context from the old
compressor) is not a header compression issue?

Br,
Zhigang

---

From: [email-masked]
Date: Fri, 30 Mar 2001 17:08:55 -0600

> Sorry that I forgot to say "unfortunately" in the beginning 

Sorry that it is unfortunate for you..

Regards,

-Rajeev

> Anyway, I do not care if someone wants to do context transfer 
> as part of the handover procedures used for certain 
> environments. Personally, I think it is overkill and makes 
> things more complicated, but that is not up to me to judge.