Subject: RE: [rohc] The discussion on slope(s) (redux)

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 9 Dec 2004 10:06:04 +0100

> Mark,
> 
> I believe 4.5.3 is quite explicit about what we send if we 
> *do* send a (scaled) timestamp. The issue we have, I think,
> is that 3095 is not very explicit about what we do when we
> *don't* send a field.

Exactly. This is the compression step. While 4.5.3 only talkes
about scaling, the actual compression step is in 4.5.3 referred
to as "WLSB or timer-based". This is indeed correct, I think,
but 3095 is not completely clear on how certain fields are
compressed based on other fields, i.e. the details TS and IP-ID
details for how to decompress them if no bits are actually sent.

/L-E

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

---

From: [email-masked]
Date: Thu, 9 Dec 2004 19:20:28 -0500

Mark,

Long email, long reply ... :-) 

BR, Zhigang

> In particular, we agree that the concept of implicit slope 
> has potential synchronisation problems; 

This is still being discussed. I have to be honest: there might 
be, but I'm not sure yet. Either way, I don't think it's a 
problem serious enough to kill implicit slope.

> and we don't believe has been actually
> implemented / tested.

Yes, it has been implemented in Nokia code. And it survived
our stress tests: injected bit corruption, packet loss, and 
even limited mis-ordering.

> However, we do think that the concept of slope is useful for 
> compressing
> timestamp efficiently (particularly in the case of video).  
> It could also,
> perhaps, have been used to solve the linux-zero-ip-id-problem..!

Yes, I still remember Mikael and I touched the slope issue when
discussing zero ip-id long time ago. Unfortunately, it was
turned down, partially due to a "bug" in 3095 text (don't remember
which one).

For me, it's hard to understand what SO state is without thinking
of slope.
 
> IP-ID is a non SN field so according to 5.1.2.2 it should 
> follow the rule:
> 
>   non-SN-field = SN * slope + offset           [1]
> 
> Fine.  But section 4.5.5 states that for the IP-ID the offset 
> should be
> compressed with LSB encoding and the offset is given by:
> 
>   Offset_i = ID_i - SN_i,                      [2]

You just hit the heart of the confusion! Three clarifications
(at least what I had in mind when writing those sections):

1) equation [1] and the concept of slope is for SO state, not FO state.
2) section 4.5.5 is about sending FO information, not SO.
3) non-SN-field does not has to be a header field. It can be
a header field after transformation, in particular, Offset_i 
and TS_SCALED. This can be evident in section 5.7 as you raised.

> Another question is: what is the expected behaviour in the 
> case where the source IP stack is sending two flows which 
> happen to be alternating packets?  This may lead to the 
> IP-ID for each flow incrementing in regular steps of 2.  
> From what's in the rfc and what we *assume* folks have
> implemented, we believe that LSBs of IP-ID-offset would be 
> sent in every packet and you'd never reach SO state. Any comments..?

With slope, you can enter SO state. I believe this has been 
discussed when drafting 3095. Oh well, so many things have 
been discussed but ...

SN                       1    2    3    4    5  ...
IP-ID                  101  103  105  107  109  ...
IP_ID Offset           100  101  102  103  104  ...
slope(IP-ID Offset)    N/A    1    1    1    1  ...
offset(IP-ID Offset)   N/A   99   99   99   99  ...
Compressor sends       CUP  CUP   -0   -0   -0  ...

Notes:
- CUP = Context Update Packet
- assume "immdieate ACKs"
 
> But, OK, let's consider timestamp.  Again it is a 
> non-SN-field so it can be expressed using equation [1]. 
> However, 4.5.3 also defines scaling using the equation:
> 
>   TS = TS_SCALED * TS_STRIDE + TS_OFFSET		[3]

Again, there are two steps as my text in 4.5.3 intended to say
1) Scale step: transform TS to TS_SCALED before compression.
This is what [3] about.
2) Compression step: compress TS_SCALED just as if it's a
"normal" TS. Here, the SO state comes as in [1]. And W-LSB
encoding for FO state.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 10 Dec 2004 09:47:12 +0100

> 2) section 4.5.5 is about sending FO information, not SO.

This is not true, 4.5.5 actually specifies exactly how to 
compress IP-ID, nothing is really missing to implement it.

4.5.5 explains what to do both with and without bits in the
compressed header, specifically note the following line:
"Note that m may contain zero LSBs for Offset_m, in which case
Offset_m = Offset_ref."

The only possible interpretation of "default-slope(IP-ID offset)"
would be to see it in light of what section 4.5.5 says, and it
actually fits well together as a slope of 0 means the same
as Offset_m=Offset_ref.

However, there is no way to find anything that indicates this
0-slope would ever change, that would also go against what is
actually specified in 4.5.5.

> > IP-ID for each flow incrementing in regular steps of 2.  

This example was mentioned at some point in the 3095 development,
but it was agreed that it is a rather non-realistic scenario that
it would not make sense to build special mechanisms for.

For IP-ID (offset), there is clearly no learned slope in 3095.

/L-E