Subject: RE: [rohc] RE: Problem of CRC in profile 4 and 2,

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 12 Jul 2002 17:25:33 +0200

After thinking a little bit more about this...

> An invalid SN might result in an incorrect ACK, but considering the
> number of SN bits used in R-mode packets, the potential problem is
> minimal for invalid SN values caused by losses. Invalid SN numbers
> caused by residual errors should not at all be a problem since 
> such errors are temporary in one packet.

Since the SN is generated by the compressor, the only SN error that
can possibly appear at the decompressor as a result of losses would
be an old sequence number, which would then (in a feedback message)
just refer to an older packet. That would not cause any problem
at the compressor, more than that it would trigger a larger header
to synchronize, which is also what is needed to correct the SN.

Have I forgotten something? This analysis gives me the impression 
that we should not have anything to worry about.

Cheers,
/L-E 

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

---

From: Kamal-deep SINGH <[email-masked]>
Date: Sun, 21 Jul 2002 23:19:18 +0200

hi,
correct me if I am wrong some where.
> that we should not have anything to worry about.

SN number instead will always be a new number because p being always -1.
SN number decoded will always be brought into the window by adding or by
subtracting interval size and hence will always be greater then the
sn_ref in decompressor and also it will be more than the maximum SN
present in the window of compressor with high probability.
After that SN will always be out of sync because new SN decoded will
allways be greater than the sn_ref present in decompressor. 
So, a little error in SN will make the decompressor sn_ref out of sync
with compressor.
Due to this ACK - NACK mechanism will fail unless compressor sends IR or
IR_DYN packet but, compressor will send these packet only in case of
update because otherwise it will never get a valid NACK so as to move to
a state IR or start sending IR_DYN.
After this if context damage occurs then evry packet will be lost untill
an update occurs. 
The cases will be different for IPv4 and for IPv6
because in IPv4 there is an IP-ID field and while calculating it
the decompressor will probably come to know abt the invalid SN but,
in IPv6 it is not the case.

I am not sure whether context damage can at all occur in this case.
but, ACK-NACK mechanism will surely fail untill an update.
kamal

---

From: Wang Hui <[email-masked]>
Date: Mon, 22 Jul 2002 10:03:13 +0800 (CST)

I am implementing the ROHC with reference to RFC3095.  Now I am do with R
mode stuffs. I find there is no CRC in R-O packets.  Why?
We neednt do CRC with R-O packets?  Why not use the UO-0 packet format instead
 of R-0 packet format?

best,

--
 Wang Hui
 Next Generation Internet Research Team,
 InfoNet Lab, USTC
 http://mail.ustc.edu.cn/~whui
 Tel: +86-551-3603634