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

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

Folks,

> > So in the IP-ID case the non-encoded field grows with SN and in the
> > Timestamp case the encoded field grows with SN.
> 
> That's my conclusion, which I would put slightly differently:
> With IP-ID, if it is not encoded in the header, it grows in 
> parallel SN.
> With TS, if it is not encoded in the header, it grows in 
> parallel with TS_STRIDE*SN (independent of Tsc!).

Which could also be expressed as:
With TS, if it is not encoded in the header, its scaled
representation grows in parallel with TS_STRIDE.

TS can thus be communicated in three ways:
1) Unscaled
2) SCALED and sent with WLSB
3) SCALED, inferred from SN

It seems like 1) and 2) are "clear" from 3095, while what is really
missing is a defined decompression (and thus compression)
logic for 3). The "default slope" value would be an important
part of that logic, and I guess most implementers have actually
used that value for the simple function
TS_SCALED=(SN-SN_OLD)*default_slope + TS_SCALED(SN_OLD)
for decompression of TS_SCALED when no TS bits are sent.

Q: Would default_slope be used when decompressing based
   on TS bits actually sent?
Q: Can default_slope be anything but 1? 
Q: Can TS bits ever be omitted when sent unscaled?

I think the answers to all these questions are all NO!
Therefore, I do not think default_slope would ever (when used)
be equal to TS_STRIDE, as stated on page 75.

To sum up, we seem to agree that either there should be no mentioning
of slope at all, or it should not be possible to change the default
slope. Personally, I read these two as meaning the same thing, but in
any case we have a strong agreement on not doing any implicit slope
updates, which is the most important point from these discussions.
 
For TS, I therefore conclude that we will have to clarify 3).

For IP-ID, 4.5.5 is very clear on how to decompress the ID with
offset IP-ID encoding, both with and without ID offset bits in the
header. Since IP-ID is always offset encoded if sent compressed,
I think there is nothing missing when it comes to IP-ID and slopes,
more than to clarify the meaning of default_slope on page 75, which
simply means exactly what is said on the second and third line of
page 35 (the additional mentioning on page 75 is thus just confusing). 

/L-E

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Dec 2004 14:15:19 +0100

> representation grows in parallel with TS_STRIDE.

s/scaled/unscaled/

(The scaled representation grows in parallel with SN.)

> TS can thus be communicated in three ways:

...and sent with WLSB

> 3) SCALED, inferred from SN

Yes.

> logic for 3).

Well, at least 3095 says that Tsc is 1 in the context, so SCALED is the 
more likely interpretation, I'd say.

> The "default slope" value would be an important

No.  4.5.3 is quite clear on what to do.

> Q: Can default_slope be anything but 1?

(If Tsc is 1:) No.  See 5.7.

> Q: Can TS bits ever be omitted when sent unscaled?

Yes, with an ext3 if Tsc is 0, R-TS is 0, and no TS bits are in the 
base (i.e., UOR-2-ID) header carrying the ext3.

> be equal to TS_STRIDE, as stated on page 75.

See the unlikely, but possible case above.
But the logic is clear: Look at Tsc, if it is 0, the default-slope is 
TS-STRIDE, if it is 1, the default-slope is 1.

> page 35 (the additional mentioning on page 75 is thus just confusing).

Yes.

Gruesse, Carsten