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

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 11 Jul 2002 21:05:39 +0200

Hi again, 

To be honest, we never had much discussions about profile 2
operation when writing RFC 3095, and we might therefore have
made minor mistakes. However, am I far from convinced yet
that there are any real problems, so let's try to figure that
out. I've looked at your concerns below, and provided some
comments.

BR
/L-E

> > >    In profile 4(IP) and profile 2(UDP) should not the
> > >    CRC be calculated over the original header "plus SN" (
> > > in case of compressed headers)
> 
> >  For CRC's there are no differences,
> > and these are therefore calculated over the original
> > uncompressed header, according to section 5.7 and
> > 5.9. The ROHC CRC is not there to serve as a CRC for the
> > transmitted data, but as a verification of correct
> > decompression, and that is the reason for having
> > the coverage as specified in RFC 3095.
> 
> Thanks for the answer . What makes me worried is when CRC
> will not cover SN then SN can be wrongly updated in the 
> context (particularly when IP-ID is not there in IPV6 and hence
> decompressed packet will be assumed correct according to the CRC)
> and ACK NACK mechenism might fail because they contain the SN of
> the Last packet decompressed correctly.

A NACK would mean decompression has failed, but you are probably
right that the SN might be wrong without knowing it. So, if this is
true, what would be the result?

> The decompressor will send the new SN with the
> ACk or NACK because it will think that its perfect as indicated
> by the CRC(though it doesnt account for the SN). But this new
> ACK or NACK will contain a SN which was never sent by the
> compressor hence compressor will discard the ACK or NACK packet
> and will keep on continuing to do so till the SN is made correct
> in the decompressor. This may lead to many packets getting lost.

The question is why packets might get lost? If the CRC had covered
also the SN, the decompressor context would had been invalidated
because of the incorrect SN, and packets would had been discarded
due to that. However, now the decompressor context does not get
invalidated and packets does not get lost due to this SN error.

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.

The questions we should ask ourselves are:
1) Is there a risk of forwarding invalid packets?
2) Is there a risk of getting a significantly
   higher probability for context damage and
   loss propagation. 

From what I can see, the answer to 1) is NO and also 2) seems
unelectable. However, it might be worth adding some words about
this to the implementer's guide, giving suggestions for how to
make compressor and decompressor implementations and reduce the
potential risk.

Comments?

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