Subject: [rohc] rohcbis and rohcv2: Some questions

From: Aniruddha Kulkarni <[email-masked]>
Date: Fri, 30 Jun 2006 12:05:47 +0200

Hi,

    After a quick look through framework, profiles, formal notation and
improvements drafts, I have some questions:
1. Why the timer-based compression scheme is not included ? It was not
discussed in improvements draft so it must be a new development.
Considering the fact that it is an optional scheme, it will not be any
overhead for those who do not want to use it. I know it is complex and
saves just 1 byte per packet but note that it saves 1 byte per packet
everytime there is silence period in VoIP and that is very common occurance.
2. Why the local-repair mechanisms are not included ? The improvements
draft suggested to make them optional. These are used only on
decompressor side and have no impact on rohc protocol but why loose
these ideas from the documents, why not atleast keep them in appendix ?
3. The same applies for reverse decompression.
4. There is no discussion regarding optimistic approach in framework
draft, it is in profiles draft. Could someone explain why this choice
has been made? I thought optimistic approach is a part of rohc framework
which all profiles follow.
5. For handling reordering, MAX_R_DEPTH parameter has been introduced.
The drafts have not discussed any direct relationship between p value
and MAX_R_DEPTH, or have I missed something? The section 5.2.2 in
profiles draft says, "The optimistic approach section 5.2.1 provides the
upper limit for the maximum reordering depth for seldom changing
fields.", can someone elaborate it further?

And a general question, is it expected that the reader should have read
RFC3095 before reading these new drafts for rohcbis and rohcv2?

Thanks,
Aniruddha

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

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Fri, 30 Jun 2006 14:59:26 +0200

Aniruddha,

> discussed in improvements draft so it must be a new development.

You are correct this has not been discussed or proposed for removal, I
guess this is a good starting point for such a discussion.

> draft suggested to make them optional.

This should also be further discussed, having implementation suggestions 
in
an appandix could be one idea.

> 3. The same applies for reverse decompression.

Not really, this one the improvements draft clearly says will go out, 
and
there were never any arguments against that.

> which all profiles follow.

Not necessarily, the profiles in 3095 do have an operational mode which
is not built on an OO. The framework is not intended to limit the
possibilities or exclude any profiles. This new framework draft is there
to make the framework explicitly clear, not to change it or exclude
previously defined profiles.

> RFC3095 before reading these new drafts for rohcbis and rohcv2?

This should at least not be a requirement specification-wise, but from
an informational perspective it will of course be useful to be aware of 
the
background.

BR
/L-E