Re: [ippm] The next steps for the reordering drafts.

Al Morton <acmorton@att.com> Mon, 21 March 2005 14:05 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06756 for <ippm-archive@lists.ietf.org>; Mon, 21 Mar 2005 09:05:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDNSj-0004Bx-Qm; Mon, 21 Mar 2005 09:00:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDNSh-0004Bk-Ta for ippm@megatron.ietf.org; Mon, 21 Mar 2005 09:00:55 -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 JAA05942 for <ippm@ietf.org>; Mon, 21 Mar 2005 09:00:54 -0500 (EST)
Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDNXm-0000LF-2Z for ippm@ietf.org; Mon, 21 Mar 2005 09:06:10 -0500
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2LE0g0a002051 for <ippm@ietf.org>; Mon, 21 Mar 2005 09:00:45 -0500
Received: from custsla.mt.att.com (135.21.14.109) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E00011D97 for ippm@ietf.org; Mon, 21 Mar 2005 09:00:45 -0500
Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.14]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id j2LE0hZ15055 for <ippm@ietf.org>; Mon, 21 Mar 2005 09:00:44 -0500 (EST)
Message-Id: <6.0.3.0.0.20050320110644.01edd400@custsla.mt.att.com>
X-Sender: acm@custsla.mt.att.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Mon, 21 Mar 2005 08:58:43 -0500
To: ippm@ietf.org
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] The next steps for the reordering drafts.
In-Reply-To: <6.2.0.14.2.20050308182456.02cb66f8@localhost>
References: <6.2.0.14.2.20050308182456.02cb66f8@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

At 12:25 PM 03/08/2005, Henk Uijterwaal wrote:
>In the meantime, the authors of draft-jayasumana-reorder-density-03.txt
>have continued their research, resulting in an -04 version of the
>draft and some related publications.   The question is whether the WG
>feels that the 2 proposed metrics (RD and RBD) are sufficiently
>distinct from the metrics proposed in draft-ietf-ippm-reordering
>to warrant a second RFC by this WG (step 3 above).
>
>We would like to hear arguments, pro and con, if the working group
>feels that either the RD or the RBD metric (or both, of course) from
>draft-jayasumana-reorder-density should become a working group item.

The Reorder Buffer Density (RBD) metric retains the foundation of
a general buffer occupancy calculation. This was the original form
of reordering density in earlier versions of this draft, including
the fact that it records buffer occupancy with loss alone
(no reordering needed to grow the buffer, and the normalization
for lost packets doesn't reduce the occupation to zero).
See section 7, example b. for a scenario with loss, no reordering.

This behavior doesn't seem to fit a reordering metric.

draft-ippm-reordering-09 deals with buffer size more effectively,
in that it only produces values when reordered packets arrive,
in the dimension of bytes.  See the Section on Byte Offset.

Al

P.S. We've been here before...

>At 11:57 AM 02/17/2003 +0100, Henk Uijterwaal (RIPE-NCC) wrote:
>>Nischal,
>>...
>>
>>2. Can you include the same examples as in the other reordering metrics
>>    so one can compare the algorithms?
>>
>>Henk
>
>Case b, packet loss (1,2,4,5,6,7) is sufficient for comparison.
>No reordered packets arrive, yet this metric reports reordering
>density.  The existing metrics maintain orthogonality between
>loss and reordering. Perhaps this algorithm would be better
>characterized as a receiver buffer occupation function.
>
>Al
>


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