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

From: "West, Mark" <[email-masked]>
Date: Thu, 17 Feb 2005 12:00:03 -0000

Hmmm...

I guess that the following snippet was causing flashbacks to another
discussion:

       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));

defines how to calculate the values at the compressor.

But something like:

	let (seq_number:uncomp_value ==
		seq_number_scaled:uncomp_value * payload_size +
			seq_number_residue:uncomp_value);

tells the decompressor how to reconstruct the uncompressed value and simply
reduces to
		(seq_number:uncomp_value == seq_number_residue:uncomp_value)
in the case that payload size is 0.  And it is clear (?) that the compressor
has to find scaled and residue values that satisfy this equation.

This is just an observation, however.  I'm quite happy with Carsten's
suggestion.  The above can just be viewed as 'fall-out' from the dreaded
'slope' discussion :-)

Mark.

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: 17 February 2005 07:44
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: Carsten Bormann; West, Mark; [email-masked]'
> Subject: Re: [rohc] Issue list for ROHC TCP
> 
> 
> 
> On Feb 17 2005, at 08:11 Uhr, Lars-Erik Jonsson (LU/EAB) wrote:
> 
> >>>>> 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.
> 
> 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
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Feb 2005 00:21:58 +0100

> 			seq_number_residue:uncomp_value);

This is not complete, or is it?

How about adding:
let(seq_number_residue:uncomp_value < payload_size || payload_size == 
0);

Gruesse, Carsten

---

From: "West, Mark" <[email-masked]>
Date: Fri, 18 Feb 2005 00:21:25 +0000 (GMT)

Assuming that this correction includes tacit acceptance for the
approach..?! (however galling it may be to find someone more pedantic than
I)

:-)

I'm not sure that the extra condition is absolutely *necessary*, but I
agree that it makes sense to include it.

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Fri, 18 Feb 2005, Carsten Bormann wrote:

> Date: Fri, 18 Feb 2005 00:21:58 +0100
> From: Carsten Bormann <[email-masked]>
> To: "West, Mark" <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>,
>      "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>,
>      "[email-masked]'" <[email-masked]>