RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

"Timur Friedman" <timur.friedman@lip6.fr> Sun, 23 February 2003 00:55 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18449 for <avt-archive@odin.ietf.org>; Sat, 22 Feb 2003 19:55:58 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N13ki19285 for avt-archive@odin.ietf.org; Sat, 22 Feb 2003 20:03:46 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N13Ap19273; Sat, 22 Feb 2003 20:03:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N10vp19223 for <avt@optimus.ietf.org>; Sat, 22 Feb 2003 20:00:57 -0500
Received: from isis.lip6.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18427 for <avt@ietf.org>; Sat, 22 Feb 2003 19:52:36 -0500 (EST)
Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id h1N0uRVR024007 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Sun, 23 Feb 2003 01:56:27 +0100
X-pt: isis.lip6.fr
Received: from doris (doris.ipv6.lip6.fr [132.227.72.166]) by tibre.lip6.fr (8.11.6/8.11.3) with ESMTP id h1N0uR303306; Sun, 23 Feb 2003 01:56:27 +0100 (MET)
From: Timur Friedman <timur.friedman@lip6.fr>
To: 'Magnus Westerlund' <magnus.westerlund@era.ericsson.se>
Cc: avt@ietf.org
Subject: RE : [AVT] draft-ietf-avt-rtcp-report-extns-02.txt
Date: Sun, 23 Feb 2003 01:56:27 +0100
Message-ID: <02cd01c2dad6$655aef30$a648e384@lip6.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3E54AB12.4040509@era.ericsson.se>
X-Scanned-By: isis.lip6.fr
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Magnus,

[I address the comments relating to the timestamp report block in this
mail.  A previous mail addressed the comments relating to signalling.]

I agree that the timestamp report block potentially uses a large amount
of space, and could benefit from compression.  The method you propose
looks promising to me.  As in the case of signalling, though, I wonder
if we could not go forward with the present format and consider this for
a subsequent draft.

We proposed the Loss RLE block, for instance, after studying a number of
different compression techniques and concluding that run length
encoding, while not always offering the best ratio, was simple and could
reliably provide 5:1 compression over a fair range, given typical
observed loss patterns.

The current format for timestamps allows timestamps to be reported in a
simple and straightforward way.  It does not preclude a future format
that would show better compression characteristics.

Best regards,

Timur

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] 
Sent: Thursday, February 20, 2003 11:17 AM
To: Timur Friedman
Cc: avt@ietf.org
Subject: Re: [AVT] draft-ietf-avt-rtcp-report-extns-02.txt

Hi Timur,

I have in the last few weeks come to some insight on where I desire to 
use some of the reporting blocks. Therefore I have two general comments 
on what I would in fact like to add to the XR format:

...

2. The timestamp report block results in extremely large reports I think

the block would much more useful if it default contains a less bandwidth

using scheme for reporting the timestamps. My proposal is to change the 
format to the following.

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=3      | rsvd. |   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      First RTP timestamp and base             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Variable length encoded diff 1| diff 2        | Diff 3 ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


My idea is to take the first packet reception timestamp as is to form a 
base. Then for each following packet only the delta timestamp value from

the previous packet is included. To save bytes this values is then 
encoded as one, two, three or four octets. This would in most case allow

for reducing this block with 50% or more. At the same time the operation

is not that complex and does not require substantial amount of 
processing. to end up on the next 32 bit boundary padding is required. 
This padding is easy to find as the number of reports are indicated with

initial and last sequence number of the packets and the thinning factor.

A simple variable length encoding would be:
0-127         1 byte with first bit = 0, i.e. 0xxxxxxx
128-16383     2 bytes in the form 0xxxxxxx1xxxxxxx
16384-2097151 3 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx
2097151-268435455 4 bytes in the form 0xxxxxxx1xxxxxxx1xxxxxxx1xxxxxxx

As this clock is running at the media clocks used it will have rates 
from 1000 up to 90000 in most case. For most packet rates that will mean

that the diff between each packet will fit into a 2 byte value instead 
of four, reducing the necessary block size with almost 50 %. I assume 
that there are smarter variable encoding. So please propose anything 
that works better.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt