Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-experimental-options-00.txt

Jerry Chu <hkchu@google.com> Mon, 14 November 2011 07:37 UTC

Return-Path: <hkchu@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB40911E80C2 for <tcpm@ietfa.amsl.com>; Sun, 13 Nov 2011 23:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.093
X-Spam-Level:
X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHkp++q-vqkS for <tcpm@ietfa.amsl.com>; Sun, 13 Nov 2011 23:37:41 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F317611E80B6 for <tcpm@ietf.org>; Sun, 13 Nov 2011 23:37:40 -0800 (PST)
Received: by gye5 with SMTP id 5so5576356gye.31 for <tcpm@ietf.org>; Sun, 13 Nov 2011 23:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=ejOHVQNickIESxSLJhnDVv1es4CY108kPwDk1LJR4NQ=; b=KjRp7ksLeV3n+u1XNKaUsr0o3qk6cJMTgXZXeF+0UQoIZEqbV7xsqnKsLBWsQt2/F0 iAWeqCZukUsxRIN/3T0w==
Received: by 10.236.180.101 with SMTP id i65mr12657937yhm.21.1321256258980; Sun, 13 Nov 2011 23:37:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.180.101 with SMTP id i65mr12657919yhm.21.1321256258772; Sun, 13 Nov 2011 23:37:38 -0800 (PST)
Received: by 10.150.43.30 with HTTP; Sun, 13 Nov 2011 23:37:38 -0800 (PST)
In-Reply-To: <4EA5DF5F.8090407@isi.edu>
References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> <4EA5DF5F.8090407@isi.edu>
Date: Sun, 13 Nov 2011 23:37:38 -0800
Message-ID: <CAPshTCgHgXa5P080dtDbPbPN8c2d0yZBr1d+ZgUHf3hOg+i8UQ@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="20cf305e27e3f61e8104b1acf1ce"
X-System-Of-Record: true
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-experimental-options-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 07:37:42 -0000

Hi Joe,

On Mon, Oct 24, 2011 at 2:57 PM, Joe Touch <touch@isi.edu> wrote:

> Hi, all,
>
> The following document describes an informal proposal I made on the list a
> while back. Hopefully we can discuss it in Taiwan.
>

This sounds like a good idea, to remove IANA involvement hence encouraging
more
rapid experiments, at a small cost of using more bytes in the precious
option space.

I have only a couple of comments:

1. "The nonce is selected by the protocol designer when the experimental
   option is defined. The Nonce is selected any of a variety of ways,
   e.g., using the Unix time() command or bits selected by an arbitrary
   function (such as a hash)."

Although the first sentence above was clear in saying the nonce was picked
statically at the design time, the second sentence almost sounded like one
picked dynamically.

Also I wonder besides pure randomness, is there other idea the can be used
to further minimize the chance of collision, e.g., including the length
field as
a differentiator or embedding some notion of calendar time in the nonce...

2. "The length of the nonce is intended to be 32 bit in network standard
   byte order. It can be shorter if desired (e.g., 16 bits), with a
   corresponding increased probability of collision and thus false
   positives."

Is one byte nonce allowed, considering how tight the option space has
become thus every byte of saving counts, or it's not worth the saving
because most stack implementations choose to alight each option...?

Also is the choice of the nonce size all up to the protocol designers?
If so, perhaps some guideline can be provided on how to minimize the
chance of collision. E.g., an experimental option with a data field
containing
possibly wide range of value may suffice with just one byte nonce because
the chance of collision is low (?). Also should the length field be
considered
as a differentiator when choosing the size of the nonce?

Jerry


> Joe
>
> -------- Original Message --------
> Subject: New Version Notification for draft-touch-tcpm-experimental-**
> options-00.txt
> Date: Mon, 24 Oct 2011 14:53:10 -0700
> From: internet-drafts@ietf.org
> To: touch@isi.edu
> CC: touch@isi.edu
>
> A new version of I-D, draft-touch-tcpm-experimental-**options-00.txt has
> been successfully submitted by Joe Touch and posted to the IETF repository.
>
> Filename:        draft-touch-tcpm-experimental-**options
> Revision:        00
> Title:           Shared Use of Experimental TCP Options
> Creation date:   2011-10-24
> WG ID:           Individual Submission
> Number of pages: 6
>
> Abstract:
>   This document describes how TCP option codepoints can support
>   concurrent experiments. The suggested mechanism avoids the need for
>   a coordinated registry, and is backward-compatible with currently
>   known uses.
>
>
>
>
>
> The IETF Secretariat
> ______________________________**_________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>