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

From: [email-masked]
Date: Fri, 21 Jun 2002 11:51:31 -0500

Hi Peter,

(Now my turn to apologize for the long delay.)

I still think it would be good if you can include the text I 
proposed in March 22 (attached since it is missing from the 
email archive). Here are the reasons:

a) It would be helpful if you can look at my text as a whole.
For example, in "Packet updating property in R-mode", there
are logical links between the bullets. "Update packet
updates both compressor/decompressor context" + "an update
packet in R-mode updates ALL header fields" ==> "less bits
are needed to convey a change", especially fields other than
RTP SN, RTP TS, and IP ID. 

b) As you pointed out, there may be redundancy with RFC 3095 if 
one reads bullet by bullet. However, what is missing and thus 
confuses implementers is the link between them. For a implementer's
guide, it is worthwhile sometime to pay a bit redundancy for clarity.

c) RE implicit update, it would not be good to lump R-mode and
UO-mode together. The are quite different in this regard.
R-mode is very simple: you update ALL header fields. For UO-mode, 
RTP SN, RTP TS and IP-ID are treated differently than other
fields. And also there are some tricky things about extensions
as clarified in section 4.9 in -00.

d) I think "R-1* packets" deserve a separate section just 
as "Extension-3 in UO-1* packets" deserves its own. Unlike 
any other packets, R-1* packets do NOT update ANY header fields, 
not even RTP SN. 

Additional comments below.

BR,
Zhigang

> -----Original Message-----
> From: ext Peter Kremer (ETH) [mailto:[email-masked]]
> Sent: May 29, 2002 3:41 AM
> To: Liu Zhigang.C (NRC/Dallas); Rohc (E-mail)
> Subject: RE: [rohc] additions to ROHC Implementer's Guide
> 
> 
> 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..."

See a) and b) above.
 
> > > > - 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."

See c) above

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

Sorry, I don't follow you. I'm proposing to clarify these rules.
Of course, I don't see problems if the rules are followed. 
(Otherwise, why did I propose them in the first place?)

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

I don't know what do you call "Enhanced mode transition procedures".
But anyway, this is one of the loose ends in RFC 3095. Since R-1* 
does not update anything, it has absolute no effect on the context 
synchronization procedure in R-mode. The compressor can send R-1* 
in any state since it leaves no "trace" on the decompressor side.
Like many other things described in your draft, this is one thing
we could have done better when rushing RFC 3095.

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

Not exactly. RE a) and b), if the changes are in RTP TS and IP-ID
how will that be handled in UO-mode and by what packet? As I
explained in c) above, R-mode and UO-mode take quite different
approach. Thus, it would be better to describe them separately.

Also, what do you mean c) "is true for other packets ..."?

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

Subject: [rohc] additions to ROHC Implementer's Guide
From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 22 Mar 2002 20:08:07 -0500

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

---

From: "Peter Kremer (ETH)" <[email-masked]>
Date: Thu, 27 Jun 2002 10:34:06 +0200

Hi,

I have general problems with your proposed text. You proposed me to include some text about topics (e.g. context updating) that is already defined in RFC 3095. Maybe your text is easier to understand but that part is already clear enough.

I have received some guidelines from Lars-Erik (as a wg co-chair). It says that the imp. guide shouldn't interpret the RFC, the goal is to clarify and not to explain.

Regarding your comment on implicit updates. I don't want to lump modes together. Section 4.7 is about a GENERAL issue, which - of course - has unique treatment in the different modes. And it also gives ONE example...

Anyway, the "Enhanced mode transition procedures" can be found in "ROHC Implementer's Guide" (draft-ietf-rohc-rtp-impl-guide-00.txt), Section 3, page 3.
http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-00.txt

Best Regards,
Peter

---

From: [email-masked]
Date: Thu, 27 Jun 2002 11:04:27 -0500

Peter,

> Maybe your text is 
> easier to understand but that part is already clear enough.

I don't think so. Actually, your own text speaks for the truth. 
When you wrote the following text, was it clear to *you* that
"An update packet in R-mode updates ALL header fields"?
And "Specifically, above applies to R-0-CRC"?

------------------------------------
4.7.  Implicit TS and IP-ID updates

   Type 0 packets (R-0-CRC, UO-0), which contain the compressed RTP
   sequence number (SN) and a CRC checksum updates not only the RTP
   sequence number.  Such packets also update RTP timestamp and IPv4 ID
   implicitly, unless there are explicit TS and IP-ID fields in the
   packet.
------------------------------------

My general problem with -00 is that it misses some issues related 
to R-mode. This is understandable as you probably are more 
familiar with UO-mode than with R-mode (and me the other way 
around). But the implementation guide should clarify all 
ROHC modes. That is what independent implementers want.
 
> I have received some guidelines from Lars-Erik (as a wg 
> co-chair). It says that the imp. guide shouldn't interpret 
> the RFC, the goal is to clarify and not to explain.

Is it really so? Can you call section 3 "Enhanced mode transition 
procedures" a clarification? And how about section 4.1 "Padding
octet in CRC"? To me, they are modifications, not clarifications.

BTW, Lars-Erik is also a co-author of the draft. Can one person
wear two hats at the same time?

BR,
Zhigang

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 27 Jun 2002 18:25:35 +0200

Peter and Zhigang,

>    sequence number.  Such packets also update RTP timestamp 
>    and IPv4 ID implicitly, unless there are explicit TS and IP-ID
>    fields in the packet.

I assume that Peter is fixing this in -01, right? Peter has received
input on -00 and that should be reflected in -01. If there are still
problems after that, just point out exactly what the problems are. 

> > the RFC, the goal is to clarify and not to explain.

Well, I think my point have always been that we must try not to
go too far with this document. The most important thing is to
clarify what is found to be unclear or missing in 3095. Further,
we can add things that people think should absolutely be added
for other reasons. For example, it was agreed to add the
"Enhanced mode transition procedures", which is not about
clarifying content of the RFC, but was requested after experiences
and discussions at "ROHC in the desert".

What I have been missing in some sections of the draft is 
explanations of why this is in the draft, i.e. what is not
clear or complete in 3095. To have such a motivation should
be a requirement before adding anything to the guide. This
is useful for the guide itself, and it also makes it easier
to judge whether we should really add it or not.

/L-E