Subject: RE: [rohc] additions to ROHC Implementer's Guide

From: [email-masked]
Date: Tue, 2 Apr 2002 11:50:19 -0600

Peter,
 
> > Packet updating properties in R-mode
> > -------------------------------------
> > 
> > The updating properties of packets in R-mode can be crystallized as
> > follows:
> > 
> > - An update packet is a packet that carries CRC. It updates both
> > compressor context and decompressor context.
> 
> I think it's already clear. <clip>

It is to clarify that update packets update compressor context.

> > - An update packet in R-mode updates ALL header fields. 
> > If the packet carry information about a field X, X is updated
> > using that piece of information. For a field Y that is not 
> > explicitly mentioned, Y is updated by the established function
> > from RTP SN to Y: Y = f_y(SN) (see ROHC section 3.4 and 5.5.1.2).
> 
> It doesn't relate to R-mode only and I think section 4.7. is 
> about the same problem.

Note the "ALL" in above statement. Section 4.7 talks only about
TS and IP-ID. That is incorrect at least from R-mode perspective.
In R-mode, you simply update ALL fields. There is no difference
between TS and IP-ID or any other header fields.

(I actually raised this issue during the "authors 48 hours" before
publishing of the RFC, which trigered the addition of "implicit" 
in updating properties in section 5.7. But that doesn't seem to
be clear enough.)

> > - A compressor expects the decompressor to follow above rules
> > and use the updated fields as references to decompress subsequent
> > packets. This allows the decompressor context follows the compressor 
> > context closely and thus improve efficiency (i.e. less bits are
> > needed to convey a change)
> > 
> > - Specifically, above applies to R-0-CRC.
> 
> 
> I'm afraid I don't understand it. What's the problem if a 
> decompressor follows these rules?

I guess you meant to say what if "a decompressor does not
follow these rules"? The answer is that when a non-SN field 
Y changes irregularly, the compressor needs to calculate how 
many bits need to be sent. For that calculation, the compressor
has to know whether Y is updated on the decompressor side by 
previous R-0-CRC packets or not.

> > R-1* packets
> > ------------
> > 
> > R-1* packets do not update either compressor context or decompressor
> > context (see ROHC section 5.2.7). I.e., they are not "remembered" by
> > either compressor or decompressor. Consequently, an R-1*  can be sent 
> > by a compressor at any state except IR state. Specifically, a compressor 
> > may send R-1* packets in SO state and that (alone) does not mean the 
> > compressor must transit to FO state. 
> 
> In R-mode upward transition is based on the received acknowledgements. 
> Since these packets don't update the context it's obvious that the 
> decompressor doesn't send ACKs (5.5.2.2.) and the compressor doesn't 
> transit to an upward state.

Sorry, I don't follow you. What you said above is not what I'm trying to 
clarify here. The example I give is actually about downward state transition, 
not upward. My text here is to clarify that R-1* can be sent in *any* state 
except IR. That is not clear in RFC 3095 and has triggered many questions
in the mailing list. Some people think R-1* can only be sent in FO state,
which is untrue.

> Regarding this logic, I fully agree with you, but it's already present 
> in the RFC. I don't see any reason to mention it again in the draft.

It is not (see above).
 
> > Below lists design goals of R-1*, but an implementer may find other 
> > usage scenarios:
> > 
> > a) to handle a transient change in packet stream (i.e. a field
> > changes its value only in current packet but then reverts back 
> > to its normal pattern). E.g. suddenly appeared extension header.
> > 
> > b) to handle the case where a header field always changes without
> > fixed pattern, but not randomly either. E.g. RTP timestamp for video
> > codecs.
> > 
> > c) to reduce the feedback traffic in an update procedure which
> > is carried over a channel with long RTT (see ROHC section 5.5.1.2)
> > 
> > d) above also reduces the memory consumption (e.g. sliding window size) 
> > on compressor and decompressor side.
> 
> I think c) applies to R-mode only, 

True.

> the others are true for the other two modes as well. 

What do you mean? The text is about R-1*, which is used in R-mode only. 

Again, R-1* was designed with a clear goal not to update *any* context,
not RTP TS, not IP-ID, not even RTP SN. It is different from UO-1*. So, 
R-1* deserves some clarifications which was not included in RFC 3095 
due to its size.

> Let's think about it and get back to your list 
> after the  next interop test (when I'll update the draft).

OK.

BR,
Zhigang

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