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

From: Peter Kremer <[email-masked]>
Date: Tue, 02 Apr 2002 14:43:16 +0200

Hi,

See my commetns inline.

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

See section 5.5.1.2.: "... only a packet carrying a 7- or 8-bit CRC can 
update the decompression context and be used as a reference for 
subsequent decompression."

Section 5.5.2.2.: "... an updating packet (i.e., a packet carrying a 7- 
or 8-bit CRC) is correctly decompressed..."

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

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

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

If you mean the "implicit update" problem then you're right. This 
section should be more general.

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

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.

> 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. Let's think about it and get back to your list after the 
next interop test (when I'll update the draft).

Best regards,

-- 
Peter Kremer, MBA                  Tel: +36-1-437-7033
Ericsson Hungary Ltd.              Fax: +36-1-437-7767
Conformance Center ETH/RL/S        Mobile: +36-30-311-2118
http://conformancelab.ericsson.se  E-mail: [email-masked]

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

---

From: Sukanta Kumar Hazra <[email-masked]>
Date: Wed, 3 Apr 2002 13:06:16 +0800 (SGT)

Hi! everyone,

A small question about ROHC implementation.

Since RFC 3096 in section 2.1, states
2. Ubiquity: Must not require modifications to existing IP (v4 or
   v6), UDP, or RTP implementations.

And RTP does not have a protocol number. Therefore how does a ROHC
implementation determine if the payload carried by UDP is RTP packet or
not?

Regards,
Sukanta

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 3 Apr 2002 10:57:21 +0200

> implementation determine if the payload carried by UDP is RTP packet or

Essentially, it has to guess.  There is no way to find out reliably.
(There was a long discussion in the 1990s if RTP packets could be made
self-describing, e.g., by giving them a separate IP protocol number.
That did not happen, for a number of good reasons.)

Note that there is no problem if the implementation guesses wrong:
RTP compression is transparent, so non-RTP bits won't be damaged.
(This was one of the strong reasons to require bit-wise transparency.)

Some heuristics that might work:

-- UDP payloads start with the bits 10xxxxxx
-- UDP payloads are at least 12 bytes

(You can't compress packet flows with RTP ROHC that don't have these
properties.)

Also, set X and P bits are probably a good indication that this isn't
an RTP packet (although that might change with new uses of RTP).

After you have seen a few packets:

-- The sequence number mostly increases by 1
-- The timestamp number increases in a regular way relative to the sequence
number
-- SSRC and PT are more or less constant
-- CC is varying slowly

(These are all the conditions that make RTP ROHC *efficient* -- again,
it "works" even in the absence of these conditions.)

If the implementation was wrong in guessing RTP, it can use the
mechanism defined in item 2 of 5.11.1 to save re-sending the context
when switching to the UDP profile.
So it is not too expensive to be aggressive in guessing RTP.

Peter: Would this make good material for the implementers guide?

Gruesse, Carsten