Subject: RE: [rohc] Issue list for ROHC TCP

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 17 Feb 2005 08:11:37 +0100

> > > > TCP-1: Does ack and seq scaling have a zero-division issue since
> > > >        they appear in the default_methods section?
> > > >
> 
> My understanding is that we should be specifying what happens at the
> *decompressor*, rather than the *compressor*.  If we can 
> stick to this, then I believe that div-by-0 goes away?

Fully agree, the question is not about the principles (sorry for being
unclear on that), but about how this is captured in the FN. The issue
came from Kristofer, maybe he can elaborate a little bit.

/L-E

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 17 Feb 2005 08:29:50 +0100

> came from Kristofer, maybe he can elaborate a little bit.

Ok, that I can do, even though both of you have seen at least one previous mail 
from me on this topic. But now, the entire list gets to see it.

In co_baseheader structure, default_methods, we have:

       let (seq_number_scaled:uncomp_value ==
                seq_number:uncomp_value / payload_size);
       let (seq_number_residue:uncomp_value ==
                mod(seq_number:uncomp_value, payload_size));

But, what if the payload_size is zero? Then the expressions above will provide 
us with a nice divide by zero. And, since this is part of default_methods, I 
guess trying to bind ANY of the co_ formats will fail. This meaning that if we 
have a zero-length payload, we cannot create any CO state packets (compressor).

So, even when the decompressor receives a packet with UNSCALED bits, it will 
have to do the residue-calculation (since default methods is part of every 
co-packet-format), and in the case of zero payload, KA-BOOM, divide by zero. 
This is not an issue for how ROHC-TCP works, it is purely a problem with how we 
express it in FN, but I'm not fond enough of the FN to actually solve this, 
therefore the issue.

/Kristofer Sandlund, Effnet AB

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Feb 2005 08:43:35 +0100

> came from Kristofer, maybe he can elaborate a little bit.

The issue is that putting into the default_format an assertion that 
only applies to a subset of the formats gets you in trouble.
There is no good way to override a default_format assertion in a 
specific format in today's FN.
(I have a couple of ideas how this could be done right but I'm not sure 
I should propose new FN features at this time).

The easy way out is to put the assertion in the specific 
compressed_formats to which it applies.  Clutter, but no new FN 
features.

Gruesse, Carsten