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

[[e-mail]]

Carsten,

> > As it is described in section 4.5.3 and other places in RFC
> > 3095, TS_STRIDE is the factor by which an RTP Timestamp is
> > downscaled before compression. Obviously, it cannot be 0 (zero).
> 
> Well, zero is not exactly prohibited, but then you couldn't send any 
> other value than TS_OFFSET, which wouldn't be too useful.

A zero TS_STRIDE would also make section 4.5.3 look weird. For example, 
"it compresses the downscaled values: TS_SCALED = TS / TS_STRIDE."

> > Example 1 (audio stream with TS_STRIDE = 160):
> >
> >             <------ String 1 ------>    <-- String 2 --->
> > SN           11  12  13  14 ...   60    61    62    63 ...
> > TS          200 360 420 580 ... 8040 16040 16200 16360 ...
> > TS_SCALED     1   2   3   4 ...   50   100   101   102 ...
> > TS_OFFSET    40  40  40  40       40    40    40    40 ...
> > slope       <--------  1 ---------->    <----- 1 ------->
> > offset      <-------- (-10)-------->    <----- (39) ---->
> 
> The problem with this picture is that it does not identify 
> which of the packets are context-updating.
> The way I read msg934, the intention of this proposal was to only 
> compute slope from the points created by CRC-checked packets.

Yes. I re-draw the picture below to make it clear. Also, I corrected
a typo (TS in packet 13). Of course, there are many different scenarios
of context-updating packets or ACKs of them being lost (see below)
I can provide additional examples with detail if needed.

             <------- String 1 -------->    <----- String 2 ------->
SN           11  12  13  14  15 ...   60    61    62    63    64 ...
Ctxt-Update   x   x   x                      x     x     x
TS          200 360 520 680 840 ... 8040 16040 16200 16360 16520 ...
TS_SCALED     1   2   3   4   5 ...   50   100   101   102   103 ...
TS_OFFSET    40  40  40  40  40 ...   40    40    40    40    40 ...
slope       <-----------  1 ----------->    <---------- 1 --------->
offset      <----------- (-10)--------->    <--------- (39) ------->


> > After the fist string, the decompressor will update the
> > linear function from SN to X depending on how many packets carrying
> > field(X) have been correctly decompressed.
> 
> I'm not sure I understand this sentence.
>
> After SN-60 and SN-61 (assuming both are context-updating), 
> the msg934 slope is 50.

In the above example, the compressor wouldn't send SN-60 as
context-updating (CU) packet, since its TS_SCALED still conforms 
to the linear pattern. The compressor would send SN-61 as CU
since it's the one that breaks TS_SCALED pattern. For packets 
after SN-61, the compressor can have different options as follows
(basically text in section 5.5.1.2 of 3095):
1) Send all of them as CU until receiving two ACKs.
2) Send some of them as CU while others non-CU, until receiving two ACKs.
3) In this example, since the slope(String 1) = slope(String 2),
the compressor can be "lazy" by doing either 1 or 2, but just waiting 
for one ACK before sending -0 packets.

Now the decompressor side:
- When it receives the first CU after -0 packets, it knows a
new string begins.
- If it received and ACKed only one CU before receiving another -0 
packet, it knows compressor is in case 3 above, which means
slope(String 2) = slope(String 1). It decompress -0 accordingly.
- Else, the decompressor knows the compressor is in case 1 or 2. 
Calculate the slope using the last two CUs that have been ACKed.

> Since you don't really know which of these actually arrived (even in 
> R-mode, you must wait for the ACKs to arrive, and some these 
> might even  be lost), 
> it will take a while before it is one again.
> This is one of the reasons I'm not a great fan of msg934 slopes.

But msg934 slope does not add much delay, since at least one CU packet 
is needed anyway to synchronize the offset.

a) if the slope of TS_SCALED is always equal to the default-slope, 
then msg934 slope also means one CU is needed. Same result.

b) Else, the new slope has to communicated to the decompressor.
Now, if we follow msg934, two CUs are needed. For R-mode, it means
RTT + another ACK (say compressor takes option 1). For UO-mode, 
it means L+1 CU packets need to be sent. The difference is just 
one packet.

Furthermore, for case b), I still need to see how exactly it would work 
without msg934. 

BR, Zhigang


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