revisit protocol constants ??

Thomas Narten <narten@us.ibm.com> Wed, 22 January 2014 18:55 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F451A0154 for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 10:55:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.436
X-Spam-Level:
X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57Gz-vjX1bcC for <ipv6@ietfa.amsl.com>; Wed, 22 Jan 2014 10:55:33 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39C1A013A for <ipv6@ietf.org>; Wed, 22 Jan 2014 10:55:33 -0800 (PST)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <ipv6@ietf.org> from <narten@us.ibm.com>; Wed, 22 Jan 2014 13:55:32 -0500
Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Jan 2014 13:55:29 -0500
Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 4FA7E6E8048 for <ipv6@ietf.org>; Wed, 22 Jan 2014 13:55:25 -0500 (EST)
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s0MItTOw6488526 for <ipv6@ietf.org>; Wed, 22 Jan 2014 18:55:29 GMT
Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s0MItToa000356 for <ipv6@ietf.org>; Wed, 22 Jan 2014 13:55:29 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-65-92-95.mts.ibm.com [9.65.92.95]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s0MItSxb000343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipv6@ietf.org>; Wed, 22 Jan 2014 13:55:28 -0500
Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s0MItRjg006080 for <ipv6@ietf.org>; Wed, 22 Jan 2014 13:55:28 -0500
Date: Wed, 22 Jan 2014 13:55:27 -0500
Message-ID: <m3y527978g.wl%narten@us.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: ipv6@ietf.org
Subject: revisit protocol constants ??
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14012218-0320-0000-0000-00000242AA5E
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 18:55:34 -0000

Here is an excerpt from my review of the stable addresses document. I
wonder if we should rethink some of the protocol constants we are
defining. The world is becoming more diverse and it seems that a "one
size fits all" notion for some protocol constants is making less and
less sense.

> Finally, I want to raise a generic issue that applies to this
> document, but really is a general problem. The document adds a random
> delay between 0 and IDGEN_DELAY in order to avoid lock-step
> behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is
> pretty long for some network technologies (think data center with 10G
> or higher interfaces). I wonder if we should stop using constants that
> are fixed and make them more dependent on actual network
> technology. E.g., 1 second seems OK for WiFi, but not for 10G.

Note that this sort of constant being as long as a second can mean it
will take that much longer to configure an address (in some cases)...

> Likewise, should you ever stop trying to configure an address if you
> keep getting DAD failures? I'm of two minds. Going forward, it becomes
> increasingly painful to require operator intervention to "fix"
> something that isn't working. That argues for never giving up. But
> what should happen then is some sort of exponential backoff should be
> used to ensure that retries happen infrequently, so as not to cause
> network problems. The current text says:

For this, I was partly also thinking about DHCPv6 where the original
spec called for the client  giving up after a certain number of
tries. That saves bandwidth, but it also means that if a client can't
find a DHC server, at some point it quits trying and won't ever try
again. And if the machine stays up and running for  several
weeks... (I'm not sure this ever even got fixed....)

Thomas