Re: [ippm] Next version of the duplicate draft

Henk Uijterwaal <henk@ripe.net> Wed, 09 July 2008 09:54 UTC

Return-Path: <ippm-bounces@ietf.org>
X-Original-To: ippm-archive@megatron.ietf.org
Delivered-To: ietfarch-ippm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A683A68E7; Wed, 9 Jul 2008 02:54:47 -0700 (PDT)
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDFE3A68E7 for <ippm@core3.amsl.com>; Wed, 9 Jul 2008 02:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.392
X-Spam-Level:
X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3HUd7IumAGh for <ippm@core3.amsl.com>; Wed, 9 Jul 2008 02:54:45 -0700 (PDT)
Received: from postman.ripe.net (postman.ripe.net [193.0.19.2]) by core3.amsl.com (Postfix) with ESMTP id 827953A6905 for <ippm@ietf.org>; Wed, 9 Jul 2008 02:54:45 -0700 (PDT)
Received: by postman.ripe.net (Postfix, from userid 4008) id 194A123F87; Wed, 9 Jul 2008 11:54:56 +0200 (CEST)
Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id B08DC23EE7; Wed, 9 Jul 2008 11:54:55 +0200 (CEST)
Received: from guest-wv-48.ripe.net (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id A94DF2F583; Wed, 9 Jul 2008 11:54:55 +0200 (CEST)
Message-ID: <48748AD2.2080409@ripe.net>
Date: Wed, 09 Jul 2008 11:54:26 +0200
From: Henk Uijterwaal <henk@ripe.net>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Henk Uijterwaal <henk@ripe.net>
References: <485BBABF.5070002@internet2.edu> <BDC0ED29-C3D8-42FC-BB12-EA9018BFD3B2@nokia.com> <4868A492.9000803@ripe.net> <BC1A81F7-4888-46EE-A5D8-04D72621939B@nokia.com> <486A285C.9040904@ripe.net> <6CCCA629-6BB3-4BEC-B93C-424AEF2A19F0@nokia.com> <486A4555.8080702@ripe.net>
In-Reply-To: <486A4555.8080702@ripe.net>
X-RIPE-Spam-Level:
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.000000 / -4.4
X-RIPE-Signature: 7af7a112e37f7ccdb6d10d9c7103ad98
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Next version of the duplicate draft
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

Hi all,

>> so what if there is no information, such as with pure TCP ACKs?
>  > I wonder - since IPPM is doing metrics for IP - if we can define
>  > duplication only in terms of the IP header fields?
> 
> Well, if there is nothing to distinguish two packets that were
> intentionally sent over a packet that has been replicated along
> the way, then one cannot use this metric.  For active measurements
> between two hosts, this won't be an issues as one generates his own
> packets and can  easily put something in to make them unique.
> For other metrics, we haven't defined the packet format or how to
> do this either.
> 
> If one wants to apply the metric for other cases (say, passive monitoring
> of TCP sequences), then one will have to find something in the packets
> to distinguish two packets from one packet sent twice.  I'm open to
> suggestions here.

This discussion seems to have stopped here.

The text says that active measurement systems MUST NOT send packets with
identical information fields, in order to avoid that all packets are
declared duplicates.   That is sufficient to use this metric in this
case.  The metric will also work for passive methods where one is sure
that each packet is different.  The metric won't work for cases where
multiple identical packets are intentionally sent.

In order to move forward:

a) We accept this (and add text to make this clear to everybody).

b) We don't accept this.  In that case, one will have to find something
    to distinguish two packets from one packet sent twice.

My preference is for the former, but I like to hear other opinions.  I'm
afraid that if we don't accept this and don't come up with good suggestions
to distinguish packets, we'll never end up with a duplication metric.


Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm