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

"Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com> Fri, 03 December 2004 18:20 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14347 for <rohc-web-archive@ietf.org>; Fri, 3 Dec 2004 13:20:31 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaI8G-0006R1-Hh for rohc-web-archive@ietf.org; Fri, 03 Dec 2004 13:26:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaEaW-0004lq-FJ; Fri, 03 Dec 2004 09:39:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaDnp-0006EX-3m for rohc@megatron.ietf.org; Fri, 03 Dec 2004 08:48:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04250 for <rohc@ietf.org>; Fri, 3 Dec 2004 08:48:51 -0500 (EST)
Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaDtZ-0003fd-4c for rohc@ietf.org; Fri, 03 Dec 2004 08:54:49 -0500
Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iB3Dmph5002582 for <rohc@ietf.org>; Fri, 3 Dec 2004 14:48:51 +0100 (MET)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Dec 2004 14:48:50 +0100
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <XVCVPWHG>; Fri, 3 Dec 2004 14:48:50 +0100
Message-ID: <A943FD84BD9ED41193460008C7918050072E99C4@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: rohc@ietf.org
Subject: RE: [rohc] The discussion on slope(s)
Date: Fri, 03 Dec 2004 14:48:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 03 Dec 2004 13:48:50.0777 (UTC) FILETIME=[D2021C90:01C4D93E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
Sender: rohc-bounces@ietf.org
Errors-To: rohc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8

> > > As it is described in section 4.5.3 and other places in RFC
> > > 3095, TS_STRIDE is the factor by which an RTP Timestamp is
> > > downscaled before compression. Obviously, it cannot be 0 (zero).
> > 
> > Well, zero is not exactly prohibited, but then you couldn't 
> > send any other value than TS_OFFSET, which wouldn't be too useful.

It is true that with a TS_STRIDE of 0, one would not be able to
scale the TS value when it actually have to be sent, but I would
not say TS_OFFSET=0 is useless, as one would be able to omit the
TS in consecutive packets with constant TS.

> A zero TS_STRIDE would also make section 4.5.3 look weird. 
> For example, "it compresses the downscaled values:
> TS_SCALED = TS / TS_STRIDE."

Yes, this formula should be replaced by the actual scaling
formula: TS = TS_SCALED * TS_STRIDE + TS_OFFSET

The TS_SCALED = TS / TS_STRIDE formula is not really good in any
case, since with an undefined "/", it could be interpretred as if
it generates a TS_SCALED that is not necessarily an integer number.  


> > > After the fist string, the decompressor will update the
> > > linear function from SN to X depending on how many 
> > > packets carrying field(X) have been correctly decompressed.
> > 
> > I'm not sure I understand this sentence.
> >
> > After SN-60 and SN-61 (assuming both are context-updating), 
> > the msg934 slope is 50.
> 
> In the above example, the compressor wouldn't send SN-60 as
> context-updating (CU) packet, since its TS_SCALED still conforms 
> to the linear pattern. 

So, you mean that you would have to force the compressor not to
send updating packets to avoid the slope being accidentially
updated? There are other reasons for sending updating packets
than to establish an implicit slope, the periodic R-0-CRC for
SN update, for example.

I still miss the full logic for how a new slope is established at
the decompressor, as well as all the rules the compressor will
have to follow to ensure it makes the correct assumptions for
which slope is established at the decompressor, and (maybe most
important) how the compressor ensures it does not accidentially
makes the decompressor update the slope. A complete picture for
all modes would be very interesting (or maybe terrifying) to see.

/L-E

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc