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

From: "Peter Kremer (ETH)" <[email-masked]>
Date: Wed, 29 May 2002 10:40:35 +0200

Hi Zhigang,

Sorry for the long delay...

> > > 
> > > 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.
Since "secure reference principle" is both used for compression and decompression it means that only a packet carrying a 7 or 8-bit CRC update the compressor and the decompressor context.

Section 5.5.1.2, 4th paragraph:
"The secure reference principle is enforced in both compression and decompression logic..."

> > > - 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.

I've updated that section in implementer's guide to be more general. Now, it's not so specific but maybe more clear and apply to any field, as well.

"4.7.  Implicit updates

If an updating packet (i.e. R-0-CRC or UO-0) contains information about a specific field X (compressed RTP sequence number, typically), then X is updated according to the content of that packet.  This packet implicitly updates all other inferred fields (i.e. RTP timestamp) according to the current mode and the appropriate mapping function of the updated and the inferred fields.

For example, a UO-0 packet contains the compressed RTP sequence number (SN).  Such a packet also updates RTP timestamp and IPv4 ID, implicitly."

> > > - 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.

No. I still ask what the problem is if a decompressor follows these rules. If nothing then we don't have to clarify anything.

If a decompressor doesn't follows these rules then - in my opinion - that decompressor isn't a correct implementation of the spec and you shouldn't use it at all. I think the RFC need not to tell how to reach the highest possible compresseion rate in case of a misbehaving implementation.

> 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.
Sorry, you're right about downward transition.

You say that R-1* packets can be sent in FO and SO states.
Then how can you interpret the last sentence of the second paragraph in Section 5.5.1.2?
"In the SO state, R-0* packets will be sent."

I think what you suggest is not a clarification but an interpretation of the RFC, which is opposite to the above referred text.

> > > 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, 
> > 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. 
You're right the text is about R-1*, and I wasn't clear enough.

I think that a), b) and c) is true for other packets or extensions that don't update the context. For example an extension-3 in a UO-1 packet can also handle transient changes.

I will add a new section "Design goals for packets and extensions that do not update the context" or something similar.

/Peter

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