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

Hi all,

as I've stated before, I don't think slope is defined in 3095, and to me that 
would be good-enough for closing this issue. But since we do not have consensus, 
let's present some problems with accepting this scheme.

The slope scheme has (at least) one patological worst case where it simply 
destroys the entire compression. (if I have managed to understand how it was 
meant to work, that is).

- Let's say we're operating in R-mode.
- The slope will only be used for decompression when packets without any TS bits 
are sent (R-0, R-0-CRC).
- The slope gets out of synch between compressor and decompressor (bit errors 
will be able to do this, especially since the slope itself would not be covered 
by a CRC). For example, let's say we got hc_slope=0, dc_slope=1. Note that the 
compressor will only see ACKs in order to update slope, it will not know _what_ 
slope value is being ACKed in the case where the decompressor gets it wrong.
- The traffic sent is video where you'd have TS: X, X, X, X, X+1, X+1, X+1, X+1 
(4 packets per video frame).
- What the compressor is likely to send will be something like UOR-2-TS, R-0, 
R-0, R-0, UOR-2-TS, R-0, R-0, R-0 (assuming immediate ACK).
   Note: From what I understand of the pRTT algorithm in 3095, it is enough to 
ACK the type 2 packets, so there is nothing in the spec to guarantee that ANY 
R-0-CRC packets will be sent.
- So, when the UOR-2-TS packets are decompressed, slope will not be used and the 
decompressor sends out an ACK which makes the compressor go back to SO state 
immediately (send R-0 packets again).
- When the R-0 packets are received, they will be erroneously decompressed due 
to the slope mismatch, but this will NOT BE DETECTED by the decompressor since 
there is no CRC on these packets (the packet with a bad timestamp value gets 
delivered out into the network). The only way a slope mismatch can be detected 
is through the reception of a R-0-CRC packet. And in this patological worst case 
stream the compressor will never produce such a packet.

So, the conclusion of this example is that all packets will be decompressed and 
delivered to the network, but 75% of them will have a bad timestamp (video 
frames spread out into a larger number of packets will get even worse figures). 
And, the decompressor will never even detect that it is doing this. Of course, 
this is a worst case situation, but I cannot see that it is _impossible_. To me, 
this situation is unacceptable and if this has even one chance in a million to 
occur, it is enough for me to say that we should not accept this scheme even if 
it had been defined in the spec.
And, if there is one worst case by just doing a quick theoretical analysis, 
there is a large chance that interop testing this will provide other near-worst 
cases (if running losses and/or BER). I also doubt that it is possible to 
specify the slope-updating mechanism well enough to get it to fully interoperate 
under lossy conditions (since the update is implicit and not crc-covered).

/Kristofer Sandlund, Effnet AB

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc