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

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Sun, 21 Jul 2002 23:46:58 +0200

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

True!

> ...and also it will be more than the maximum SN present in the
> window of compressor with high probability.

This is not correct. When the packet was compressed, it created
exactly the same value in the compressor context sliding SN window.
A value might be missing at the decompressor side, due to losses
between compressor and decompressor, but not the other way around.

Losses can therefore only result in "old" decompressor values,
which is not a problem as previously discussed.

/L-E

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

---

From: ksingh <[email-masked]>
Date: Thu, 25 Jul 2002 02:35:01 +0200

Hi,

>which is not a problem as previously discussed.
I seem to follow your analyses and, have some questions --->
Will not finding of this OLD SN depend on maximum window width, infact 
on window width
in R mode( since it may get shrunk on receiving ACK).?

Since, a maximum slip of  +2^(k -1) can occur in SN(once an error occur 
)thus, a window width of 2^(k-1) + 1 in the compressor should be 
sufficient for your analyses. (k are the number of bits sent when error 
occured)

But will this width be maintained?

have I followed you correctly?

kamal