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

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

Folks,

Unfortunately, it seems like I was wrong when I hoped we would be
able to easily close this issue, I got over-optimistic by the
sense of the room at the Washington DC meeting. The discussions
in March/April died with no conclusion and all involved parties
got tired of repeating the same arguments over and over again
without getting any closer to an agreement. Since then, I have
also had the feeling that this will require a detailed analysis
of the slope/non-slope algorithms, to be able to answer the
questions I earlier outlined, which is the way I still think we
will have to go to get closure on the issue:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02085.html
However, it seems like this requires that someone seriously looks
at this problem from both perspectives so that everyone can see
what we have to decide upon. This will be resource-demanding, 
while I do not think it will be very tricky to write the final
clarifying text in the implementer's guide. As always, it is the
preparation work that takes time. I expressed this feeling both
in San Diego and in Washington, and although the response in
Washington was that we should not make this to complicated but
just get rid of slopes, I am still pretty sure after last weeks
mails on the list that we will have to spend some effort on this.

Personally, I am still sure there is no need for a learned slope,
and I can not see why we should expand the 3095 text and logic
to capture it, when something like it is only mentioned (but not
even close to defined) at a few places in 3095. However, that is
my opinion and others disagree, so I am afraid we might have to
do the detailed analysis before we will be able to get (at least
a rough) consensus on this.

However, I would like to make a few observations on what makes
me so confident in what is the "right" solution, apart from my
own opinion on the technical problem.

There are only two implementers whose implementations have made
it to all interop meetings, and who have thus learned ROHC RTP
from the specification, implemented it, got it to interoperate,
and also discussed/tested the TS encoding at an interop meeting
to get a clear opinion on the slope question. Their opinions
have been expressed in this ongoing mail thread:

Vick:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02097.html

Kristofer:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02033.html
http://www1.ietf.org/mail-archive/web/rohc/current/msg02062.html
http://www1.ietf.org/mail-archive/web/rohc/current/msg02071.html
http://www1.ietf.org/mail-archive/web/rohc/current/msg02081.html
(the last one included questions to Zhigang, which were ignored)

Finally, I would like to send a direct appeal to Zhigang, as a
comment on yesterday's mail on this subject:

> ZL:
> I think it's fair to also look at the arguments that dynamic
> (or learned or implicit) slopes are in 3095. I have given some
> back in March/April. Below is one of them. If I have to summarize
> in one sentence, the argument is that if dynamic slopes are not
> in 3095, many text (some are essential to encoding) wouldn't 
> make sense without twisting hard the meaning of words.
> http://www1.ietf.org/mail-archive/web/rohc/current/msg02101.html

Can you then list these parts, please cut and paste the sentences
in an e-mail, do not use references. A previous proposal for what
to clarify in the implementer's guide to get rid of the confusing
slope wordings can be found at:
http://www1.ietf.org/mail-archive/web/rohc/current/msg02089.html
The attempts to clarify the slope concept and actually define it
have been much more complicated, which I also think is necessary
if we go that way.

BR
/L-E

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 02 Dec 2004 15:25:02 +0100

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Dec 2004 17:58:46 +0100

> the slope itself would not be covered by a CRC

Kristofer,

what do you mean by this?

If we assume the msg934 model for slopes 
(http://www1.ietf.org/mail-archive/web/rohc/old-archive/msg00934.html), 
the slope is established from CRC-protected packets only.
(Since ACKs can get lost, there is still some uncertainty what slope is 
actually established, so the compressor has to be careful about what it 
has sent, but this is a detail.)

Of course, the slope itself indeed is not protected.
Also, of course, CRC-protected packets still have a non-zero 
probability of bit errors being uncaught.

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 03 Dec 2004 08:35:35 +0100

> has sent, but this is a detail.)

Yes, of course the update packet itself has a CRC. But the slope value is not 
transmitted, it is inferred based on timestamp history so it is not covered by 
that CRC. So, maybe I should have spelled that out, but I figured that should 
have been clear from earlier discussions.

> Also, of course, CRC-protected packets still have a non-zero probability 
> of bit errors being uncaught.

Exactly what I meant.

/Kristofer