RE: [rohc] Mode Information in IR/IR Dyn Packets (UDP Profile/ESPprofile)

["Rambabu Gajula" <rambabu.gajula at ccpu.com>]

Thanks a lot Kristofer.


I have following query regarding the IP Identification (IPV4) number
used 
across the ROHC RFC 3095).


>From Section 3.4:
IPV4 Identification (16bits) ---> IP-ID

RND: Flag indicating whether the IP-ID behaves randomly.


Here the IP-ID presenting the IP Identification of IP header(IPV4) or
(IP Identification - SN )?


To predict the random behavior, shall we consider the random ness with
in IP Identifications (IPV4), by comparing with the previous packets IP
Identifications values or 

Off Set IP- ID(off set = IP Identification - SN) for current packet with
the previous packets?


>From Section: 4.5.5
IP-ID for m = decompressed SN of packet m + Offset_m

The above statement gives impression for me IP-ID is IP Identification
of IP header(IPV4).


In Packets type-0, type-1, type-2 we have IP-ID as representations which
is (IP Identification - SN).

The one which is carrying in ROHC General Form for Compressed RTP
packet(IP-ID for Inner IPv4 header, 2 octets if value RND = 1).

Is this value is IP Identification (IPV4) or     (IP Identification
-SN)?


Thanks a lot for your help and time.

Regards,
Rambabu Gajula




-----Original Message-----
From: Kristofer Sandlund (LU/EAB)
[mailto:kristofer.sandlund at ericsson.com] 
Sent: Friday, August 17, 2007 1:26 PM
To: Rambabu Gajula; lars-erik.jonsson at ericsson.com; rohc at ietf.org;
aniruddha.kulkarni at effnet.com
Subject: RE: [rohc] Mode Information in IR/IR Dyn Packets (UDP
Profile/ESPprofile)

Hi,

comments inline.

Rambabu Gajula <mailto:rambabu.gajula at ccpu.com> wrote on den 17 augusti
2007 06:21 :

> Hi ROHC Experts,
> 
> 
> 
> I am new to the ROHC RFC(3905).
> 
> 
> 
> I have couple of queries regarding the ROHC.
> 
> 
> 1) During Context Relocation Request, how Source RNC
> (compressor) will communicate the Mode information to the Target RNC
> (Compression). 
> 

First of all, the ROHC WG has not specified any type of context 
relocation procedure, so I cannot answer your question for any 
specific technology using any such procedure. But generally, any
context relocation scheme that assumes that it is possible to 
continue compression by transferring an IR header is inherently broken.
(personally, I would say that any ROHC context relocation procedure 
will be broken, but that's a whole other discussion)
To compress with ROHC, you need a lot more infomration than just one 
header, you need a lot of state which is built up over time such as
mode information, sliding window of contexts to use the optimistic
approach, control fields, list compression items not currently present
in the reference header etc.

> 
> 
>     IR packets (Static part + Dynamic part) not have any mode
> related information in case of UPD Profile/ESP profile.
> 

Yes, this is one example why such a context relocation scheme is broken,
and why an IR header is not enough to use for this.

> 
> 
> 2)  During Mode Change Operation at Compressor side,  the
> compressor should choose IR/IR Dyn pkt/UOR2(SN, Mode) after
> receiving the mode change request from decompress or.  But in
> case of IR /IR Dyn packets UDP/ESP profile we can not send Mode
> related information. 

And here's another example, if you transfer in the middle of a mode
transition, you would need to know the state of the transition
(e.g. D_TRANS) which is not part of an IR header.

Summary: Context relocation/transfer is something that has not
been 'blessed' by this WG, and any existing scheme for such a
technology has not been specified here.

BR,
   Kristofer

> 
> 
> 
> 
> 
> I would really appreciate your help.
> 
> 
> 
> Thanks with regards,
> 
> Rambabu Gajula



_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc