Re: Reordering for profile 0x0102 and 0x0104: RFC 5225

Vamsi krishna,

Vamsikrishna wrote:
> 
> Dear RoHCers
> 	
> 	I have a small confusion whether do we need to give the
> support of Reordering for profile 0x0102 and 0x0104 or not?
> 
> In RFC 5225, he generally speaks "ROHCv2 profiles, however, 
> can handle robustly and efficiently a limited amount of 
> reordering after the compression point as part of the 
> compression algorithm itself."
> 
> Does it mean profiles 0x0102 and 0x0104 can handle reordering?
> 
I think you will find the answer in RFC5225 section 4.3. "Operational
Characteristics of ROHCv2 Profiles". Note that the text you are refering
to is in section "Improvements of ROHCv2 over RFC 3095 Profiles" and is
a general description of differences between RFC3095 and RFC5225.

Other recommended reading would be section 5.1.1. "Optimistic Approach"
and section 5.1.2. "Tradeoff between Robustness to Losses and to
Reordering".

> But RFC 5225 tells to refer RFC 4224 for the impacts of 
> out-of-order delivery on profiles based on rfc3095. And in 
> Section 3.1 and 3.2 of RFC 4224 Tells to assaign 
> interpretation interval offset p to -1 for profiles 0x002 
> and 0x004. And more over RFC 4224 says these suggestions are 
> applicable for the design of new profiles.
>  
> If Reordering is not supported for profiles 0x0102 and 0x0104
> What is the need of communicating reordering_ratio value in 
> Co_Common packet type, because it is already communicated through
> IR and Co_Repair packets?
> 
It was a design decision. We have several other fields that are present
in several different packet types: TOS, TTL for example. I can think of
more than one reason to have reordering_ratio in co_common. For example
a cheap way of changing reordering_ratio etc.

> If a channel is configured with UDP(0x0012) or IP(0x0104) profiles
> Does the channel has to guarantee us sequence delivary?.
> 
see RFC5225 section 4.3.


Best regards,

/Calle