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

From: [email-masked]
Date: Fri, 22 Mar 2002 19:08:07 -0600

Hi,

I think below are useful texts to be included in the guide. They
came from my coding experience. Most of them have been discussed in
the ROHC list but considered as too detailed to be included in the
already long RFC 3095. They are also among the "FAQs" in ROHC list.

Zhigang

==============================================================

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.

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

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

[zliu: section 4.7 in current draft is not accurate about R-0]

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. 

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.

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