Subject: RE: [rohc] The discussion on slope(s) (redux)

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 9 Dec 2004 14:22:57 -0000

Hi again,
> 
> >> The issue we have, I think, is that 3095 is not very explicit about
> >> what we do when we *don't* send a field.
> >
> > I think that 3095 is not very explicit about *whether/when* 
> we don't 
> > send a
> > field, as well as what we do when we don't send it.
> 
> Well, that rule is simple: You can only "not send" if the 
> decompressor 
> will regenerate the right header!
> So the rule is implicitly created from the rule that says what the 
> decompressor will do if a field is not encoded in the header.

Agreed, but as far as I can see, the RFC doesn't say what the decompressor
will do if a field is not encoded in the header.  In particular, 4.5.3 only
states the translation from TS_SCALED back to full TS.  It makes no mention
of what to do if no bits are received.  

> The problem is that a lot of other places also just say "TS" 
> and really 
> mean "the thing that you get out of section 4.5 to encode TS".

OK, fair enough.
> 
> >> Both mean the same: the default value for a non-encoded field is
> >> growing with the SN, both IP-ID slope and TS-scaled slope are
> >> set to 1.
> >
> > I'm a bit confused here.  In the IP-ID case we have:
> >
> > Non-encoded field = IP-ID
> > Encoded field = IP-ID-offset
> > Default slope of encoded field stated = 0 (as stated in 5.7)
> > Implies slope of non-encoded field = 1
> 
> Yes.
> 
> > In the Timestamp case we have:
> >
> > Non-encoded field = TS
> > Encoded field = TS_SCALED
> > Default slope of encoded field stated = 1 (assuming TS in 5.7 is 
> > TS_SCALED)
> > Which says nothing about the non-encoded field.
> 
> No.  Neither did I, above?

OK, we are probably using different definitions here.  I assumed that by
encoded field you meant the field for which bits are sent.  By non-encoded
field I assumed you meant the original field from the uncompressed header,
that can be inferred from the bits sent.  So for the IP-ID and timestamp
cases I assumed you meant:

> > Non-encoded field = IP-ID
> > Encoded field = IP-ID-offset

> > Non-encoded field = TS
> > Encoded field = TS_SCALED

So in your sentence:
> >> Both mean the same: the default value for a non-encoded field is
> >> growing with the SN, both IP-ID slope and TS-scaled slope are
> >> set to 1.

I agree that both IP-ID slope and TS-scaled slope are set to 1, but they are
not both non-encoded fields (which is the implication of the first half of
your sentence).

I think this may be a language interpretation issue rather than a technical
one ;-)
> 
> > So in the IP-ID case the non-encoded field grows with SN and in the
> > Timestamp case the encoded field grows with SN.
> 
> That's my conclusion, which I would put slightly differently:
> With IP-ID, if it is not encoded in the header, it grows in 
> parallel SN.
> With TS, if it is not encoded in the header, it grows in 
> parallel with 
> TS_STRIDE*SN (independent of Tsc!).
> 
I agree with these statements and Lars-Erik's interpretation of these into
what implementer's have actually done - if this statement holds true, no
bits are needed:
TS_SCALED=(SN-SN_OLD)*default_slope + TS_SCALED(SN_OLD)

> > When doing our implementation, and in a (possibly vain) attempt to 
> > harmonise
> > the handling of TS/IP_ID, we *conceptually* treat it as:
> >
> > 'Non-encoded' field = TS_SCALED
> > 'Encoded' field = TS_SC_OFFSET
> > Assumed default slope of encoded field = 0
> > Implies slope of non-encoded field = 1
> > *BUT* when bits are required for 'encoded' field, actually 
> *send* bits 
> > of
> > 'non-encoded' field (and hope that the other end will interpret it
> > correctly..!)
> 
> You lost me.
> Maybe "non-encoded" and "encoded" mean something different 
> here than in 
> my mind...
> 
Does the definition of non-encoded and encoded above help?

We used this as an internal mechanism to decide when to send bits of
TS_SCALED in the same way as we do for IP_ID.  (As you say, determining
whether or not the decompressor will be able to correctly decompress the
packet.)

Two further points are:

It appears that IP_ID offset bits are sent in order to minimise the number
of bits required when there is jitter.  As TS_SCALED is the only other
(non-SN) field that uses LSB, we (optimistically) assumed it would/tried to
make it work in the same way.

By sending bits of offset for IP_ID, you explicitly transmit the offset
value (some/no bits) and then use the slope equation (non_SN_field = slope *
SN + offset) to get back to the IP_ID.
However, in the timestamp case, you can use the slope equation when no bits
are sent, but if bits are sent, the slope is ignored.  The bits that are
sent allow you to directly re-create TS_SCALED without any reference to
slope.

> >> In summary, I believe the text of 3095 supports your proposal 1.
> >
> > I'm not sure which you're referring to as proposal 1?
> 
> The first one of:
> 
> >>> Therefore, with respect to the implementers' guide, our 
> proposal is 
> >>> that
> >>> it should either:
> >>>
> >>> - indicate that the concept of slope exists; but that there is no 
> >>> way to
> >>> change the 'default' slope and that the slope for both IP-ID and 
> >>> TS_SCALED
> >>> is 1; or
> >>>
> >>> - that the concept of slope is ill-defined and should not 
> be used, 
> >>> at all.
> 
> I would maybe word it slightly differently, as the text 
> explicitly says 
> that "default-slope(IP-ID offset) = 0", which of course *is* 
> equivalent 
> to "default-slope(IP-ID) = 1".
> 
OK, that's fine by us :-)

Best regards, 

Abbie

> Gruesse, Carsten

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

---

From: "Basudeb Gupta" <[email-masked]>
Date: Fri, 10 Dec 2004 12:01:25 +0530

Hello Mr. Abigal,

We are designing a UDVM ( delivery date 11th December) and are stuck in the 
COPY-OFFSET torture test for last 2 weeks now. Everything else is passing 
except this.

We need your help in a few matters in the torture text document and the 
definition of COPY-OFFSET urgently. Will  appreciate greatly if I can get it 
as early as possible.

I am writing below each step in the torture test. Please help me correct our 
implementation and understanding of the 3320 RFC.

===================== Torture test steps and our results ==========
3.7.  COPY-LITERAL and COPY-OFFSET

   This section gives assembly code to test the COPY-LITERAL and COPY-
   OFFSET instructions. The code is designed to test similar boundary
   cases to the code for the COPY instruction, as well as the following
   condition specific to COPY-LITERAL and COPY-OFFSET:

   1. The COPY-LITERAL or COPY-OFFSET instruction overwrites the value
   of its destination or offset operand.

   at (64)

   :byte_copy_left                  pad (2)
   :byte_copy_right                 pad (2)
   :destination                     pad (2)
   :offset                          pad (2)

   at (128)

   LOAD (32, 16384)
   LOAD (byte_copy_left, 64)
   LOAD (byte_copy_right, 128)
   LOAD (destination, 33)

UDVM MEMORY DUMP (Start + 32)
0x0043FD70 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x0043FD80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x0043FD90 00 40 00 80 00 21 00 00 00 00 00 00 00 00 00 00

0x0043FDA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

   COPY-LITERAL (32, 128, $destination)
   COPY-LITERAL (68, 8, $destination)

>>MEMORY DUMP (Start + 32)

0x0043FD70 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD80 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD90 40 40 40 40 00 69 40 40 40 40 40 40 40 40 40 40

0x0043FDA0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FDB0 40 00 61 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FDC0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

   LOAD (byte_copy_left, 66)
   LOAD (byte_copy_right, 74)

>>Memory Dump (Start + 32)
0x0043FD70 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD80 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD90 00 42 00 4a 00 69 40 40 40 40 40 40 40 40 40 40

0x0043FDA0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FDB0 40 00 61 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FDC0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

   COPY-OFFSET (8, 6, $destination)

>>UDVM Memory Dump: (Start + 32)

0x0043FD70 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD80 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD90 00 42 00 4a 00 6f 40 40 40 40 40 40 40 40 40 40

0x0043FDA0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FDB0 40 00 61 40 40 40 40 40 40 00 61 40 40 40 40 40

0x0043FDC0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

   LOAD ($offset, 1)

   COPY-OFFSET ($offset, 5 ,$destination)

>>UDVM Memory Dump: (Start + 32)

0x0043FD70 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD80 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FD90 00 42 00 4a 00 74 40 40 40 40 40 40 40 40 40 40

0x0043FDA0 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40

0x0043FDB0 40 00 61 40 40 40 40 40 40 00 61 40 40 40 40 40

0x0043FDC0 40 40 00 4a 40 40 40 40 40 40 40 40 40 40 40 40

   OUTPUT (32, 48)

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
============================================================
   The expected output of the code is 32 instances of 0x40 followed by
   0x0042 004a 0074 4040 4040 004a 0074 4040. The expected cost of
   executing the code is 208 UDVM cycles.

Please help!!! And only you can help me here.

Thanks and Regards,
Basudeb

_________________________________________________________________
Microsoft’s festive bonanza! Buy a branded Home PC. 
http://server1.msn.co.in/sp04/festivebonanza/ Win a fabulous holiday!