Subject: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 7 Oct 2004 07:52:20 +0200

ROHCers,

An implementer sent me questions regarding section 5.4.1.1.2 of RFC 3095,
specifically about how to interpret the text on compressor behavior
(implementation) for adapting to such optional acks. After discussing
with other independent implementers, I think some clarifications are
needed to this text. 

5.4.1.1.2.  Optional acknowledgments, upwards transition

   In addition to NACKs, positive feedback (ACKs) MAY also be used for
   UOR-2 packets in the Bidirectional Optimistic mode.  Upon reception
   of an ACK for an updating packet, the compressor knows that the
   decompressor has received the acknowledged packet and the transition
   to a higher compression state can be carried out immediately.  This
   functionality is optional, so a compressor MUST NOT expect to get
   such ACKs initially.

   The compressor MAY use the following algorithm to determine when to
   expect ACKs for UOR-2 packets.  Let an update event be when a
   sequence of UOR-2 headers are sent to communicate an irregularity in
   the packet stream.  When ACKs have been received for k_3 out of the
   last n_3 update events, the compressor will expect ACKs.  A
   compressor which expects ACKs will repeat updates (possibly not in
   every packet) until an ACK is received.

A common answer from implementers is "as a decompressor, I never send
such acks, and as a compressor I do not look for them or try to change
my strategies based on the potential use of them".

This approach is of course fine and safe, and even if you want to send
the optional acks you will not run into any problems at the decompressor
side. However, if an implementer wants to let his compressor adapt to
potential use of such acks, as the 3095 text might encourage an 
implementer to do, the current text is in my opinion not sufficiently
detailed on all aspects an implementer must take into account to make
this operation safe. There is one conceptual algorithm being described
to figure out as a compressor whether UOR-2 acks can be expected, but
the text does not explain clearly what to consider when setting values
for parameters k_3 and n_3, or the importance of not making over-
optimistic assumptions of UOR-2 ack usage. As acks might be sent for
other reasons, for example the decompressor might think that he'd like
to send over the clock resolution or a loss option, or initiate a mode
transfer (which is something that clearly can happen in mid-stream), 
the compressor must be sure not to interpret that as a signal from the
decompressor to always expect UOR-2 acks. 

I am not saying the 3095 text is actually wrong, but it might encourage
an implementer to do "fancy" things, without spelling out all aspects
to consider to get a safe implementation. Therefore, I suggest the 
following (or something along these lines) to be added as a new section 
in the implementer's guide:

8.12. When to expect UOR-2 ACKs in O-mode

    Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in
    O-mode, and explains a conceptual algorithm for a compressor to
    determine whether such ACKs can be expected from the decompressor,
    simply using a condition based on unspecified parameters
    k_3 and n_3. However, what is not clearly pointed out is the
    importance of being very careful when implementing this
    confidence algorithm, as using an incorrect expectation on
    UOR-2 ACKs as a basis for compressor behavior will significantly
    degrade the compression performance. If a compressor
    implementation wants to adapt its optimistic approach behavior
    on potential UOR-2 ACK usage, the confidence algorithm for 
    determining UOR-2 ACK usage must be carefully designed, with
    k_3=n_3>>1, as UOR-2 ACKs can be sent from a decompressor for
    other purposes than to actually acknowledge the UOR-2 packet,
    e.g. to send feedback data such as clock resolution, or to
    initiate a mode transfer. Before adapting a compressor to the
    potential use of UOR-2 ACKs, the implementer must ensure all
    these aspects are considered in the confidence algorithm.

    It should again be noted that the use of UOR-2 ACKs in O-mode
    is indeed optional, so a decompressor can send ACKs for other
    purposes than actually acking the UOR-2, without then having
    to continue sending them for all UOR-2. Similarly, compressor
    implementations can totally ignore UOR-2 ACKs for the purpose
    of adapting the optimistic approach strategies.
    
Comments?
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 8 404 29 61

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 13 Oct 2004 13:16:02 +0200

>     k_3=n_3>>1, as UOR-2 ACKs can be sent from a decompressor for

I think I agree that k_3 and n_3 must be much larger than 1, but I think that k_3=n_3>>1 is wrong (i.e. the "k_3=n_3" bit) since this essentially means "for a number X of consecutive UOR-2". This would also mean that in the presence of packet losses (either compressed packets or ACKs), such confidence would likely not be achieved very often - if k_3 and n_3 are much larger than 1 and the packet loss rate is somewhat high.

>     of adapting the optimistic approach strategies.

Imo, the above text should be rewritten to provide a stronger recommendation to avoid having compressors trying to create confidence about acks to UOR-2 and just use the optimistic approach as usual. I think this part in itself is a fair example of overspecification - would 3095 be rewritten I doubt I would like to see that text in. The above suggested text should then be moved as the first paragraph of the section.

I think that this section of the implementer's guide (8.12. When to expect UOR-2 ACKs in O-mode) should be renamed "8.12. Expecting UOR-2 ACKs in O-mode". "When to expect" is still as suggestive as 3095 is regarding this.

Sorry I couldn't comment before you updated the draft, I was sick in bed for a few days...

/Ghyslain

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 13 Oct 2004 13:22:00 +0200

Comments inline...

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> Sent: den 13 oktober 2004 13:16
> To: Lars-Erik Jonsson (LU/EAB); [email-masked]'
> Subject: RE: [rohc] Confusing text in section 5.4.1.1.2 of RFC 3095
> 
> 
> > 
> I think I agree that k_3 and n_3 must be much larger than 1, 
> but I think that k_3=n_3>>1 is wrong (i.e. the "k_3=n_3" bit) 
> since this essentially means "for a number X of consecutive 
> UOR-2". This would also mean that in the presence of packet 
> losses (either compressed packets or ACKs), such confidence 
> would likely not be achieved very often - if k_3 and n_3 are 
> much larger than 1 and the packet loss rate is somewhat high.

True, k_3 and n_3 is not very useful tools to describe what a
compressor should do to get confidence. I'll rewrite this.
 
> Imo, the above text should be rewritten to provide a stronger 
> recommendation to avoid having compressors trying to create 
> confidence about acks to UOR-2 and just use the optimistic 
> approach as usual. I think this part in itself is a fair 
> example of overspecification - would 3095 be rewritten I 
> doubt I would like to see that text in. The above suggested 
> text should then be moved as the first paragraph of the section.

That would be fine with me, I agree with your motivation.
 
> I think that this section of the implementer's guide (8.12. 
> When to expect UOR-2 ACKs in O-mode) should be renamed "8.12. 
> Expecting UOR-2 ACKs in O-mode". "When to expect" is still as 
> suggestive as 3095 is regarding this.

True!

/L-E

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 20 Oct 2004 13:07:13 +0200

Ghyslain and others,

I've reworked the text, ok?

/L-E

8.12. Expecting UOR-2 ACKs in O-mode

It should be noted that the use of UOR-2 ACKs in O-mode, as discussed in section 5.4.1.1.2, is indeed optional, so a decompressor can send ACKs for other purposes than actually acking the UOR-2, without then having to continue sending them for all UOR-2. Similarly, compressor implementations can totally ignore UOR-2 ACKs for the purpose of adapting the optimistic approach strategies. Current implementation experience also suggests using that approach, and the recommendation is thus to not make use of the optional ACK mechanism in O-mode, neither in compressor nor in decompressor implementations.

For implementers who still want to make use of the optional O-mode acks, the following clarifications should be taken into account. Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode, and explains a conceptual algorithm for a compressor to determine whether such ACKs can be expected from the decompressor, simply using a condition based on unspecified parameters k_3 and n_3. However, what is not clearly pointed out is the importance of being very careful when implementing this confidence algorithm, as using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. If a compressor implementation wants to adapt its optimistic approach behavior on potential UOR-2 ACK usage, the confidence algorithm for determining UOR-2 ACK usage must be carefully designed, with k_3 and n_3 having values much larger than 1, as UOR-2 ACKs can be sent from a decompressor for other purposes than to actually ac!
 knowledge the UOR-2 packet, e.g. to send feedback data such as clock resolution, or to initiate a mode transfer. Before adapting a compressor to the potential use of UOR-2 ACKs, the implementer must ensure all these aspects are considered by the confidence algorithm.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 13 oktober 2004 13:22
> To: Ghyslain Pelletier (LU/EAB); [email-masked]'